[Nasm-bugs] [Bug 3392533] Considerations for segment support in ELF

[noreply-nasm at gorcunov.org]

https://bugzilla.nasm.us/show_bug.cgi?id=3392533

--- Comment #39 from H. Peter Anvin <hpa at zytor.com> ---
The problem with that notion is that for external far symbols to work, you
*have* to be able to obtain both the segment base and segment offset for that
symbol, and they are two separate values. Furthermore, they are a property of
the symbol itself, not a property of the location of the symbol.

I want this to work for applications other than just MS-DOS EXE files, too. 
Given that, using VMA/LMA really doesn't work, because that overloads a whole
different set of functionality. I also don't see any sane way that would work
for huge segments.

The PSP is weird: it is a 256-byte NOBITS segment at offset -256 from MZEXE
relocation origin. It is *not* at "zero", unless you are building a .com file.
(This can be addressed trivially when constructing the EXE file, so it isn't
inherently necessary to burden 

The only valid relocation in .exe is a 16-bit segment relocation (R_386_SEG16).
To produce an .exe file, you'd have to do one of the following:

1. Link with --emit-relocs and postprocess (i.e. an elf2exe program). The
"reloc" program in the Linux kernel contains all the ELF-parsing code you would
need and should be easy enough to modify to produce MZ exe files; most of it is
taking code out.

2. Link with -pie (but don't *compile* with -fPIE for efficiency), convert to
binary and just tag on an EXE header without any relocations (which could be
done via dedicated section or in the linker script directly); then stuff an ELF
relocator (parsing the .dynamic section, specifically the data from the DT_REL
pointer) at the end (what will be the _BSS section.) This will be larger in
size, but would be able to handle arbitrary relocations (really handy if you
want to jump in and out of protected mode!) and would naturally extend to
supporting dynamic libraries.

I suspect it is not any *slower* than relying on DOS' own relocator; the work
they would do would be very similar anyway.

[This may be a case where we need relocations corresponding to R_386_RELATIVE,
specifically the equivalent for R_386_16 and R_386_SEG16; either that or make
the linker able to emit those relocations into a .dynamic section without a
symbol, with the understanding that they are self-relative the same way
R_386_RELATIVE is.]

3. Add an mzexe BFD backend for objcopy or ld to use.

-- 
You are receiving this mail because:
You are watching all bug changes.
You are on the CC list for the bug.