[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 #89 from H. Peter Anvin <hpa at zytor.com> ---
1) Should the calculation for R_386_SEG16 be A + ((S + B) >> 4) rather than A +
(S >> 4)?

No. R_386_SEG16 is used for object files (.o); B is undefined at this point.



2) What should be the correct way to convert the values to segment selectors? 
More precisely, suppose we define a notional function M(X) to map linear
addresses to segment selectors --- then should R_386_SEGRELATIVE be defined as
A + M(B) or M((A << 4) + B)?  (I think the latter makes more sense.  But if it
rather assumes that IA-16 segments are start at 16-byte boundaries --- and
protected mode code does not really need this restriction.)

The latter. The limitation that x86 segments start at 16-byte boundaries and
that the address space is limited to 1 MiB (neither of which is true in 16-bit
protected mode, which has arbitrary alignment and a 512 MiB address space
limit) is imposed in this case by the fact that the i386 ELF ABI is using REL
relocations. RELA relocations (as used in the x86-64 ELF ABI) would give some
more flexibility for situations like this.

I do actually address this in the document, although perhaps not quite as
clearly.


3) Should there also be an R_386_SUB8 relocation, in parallel with R_386_8?  I
suspect such a thing might be useful in certain weird cases, e.g. where one
knows that a variable will be in the first 256 bytes of an IA-16 segment.

I talked to H.J. about it, and he said he'd rather see a need for it before
adding it; similar to adding any support to the x86-64 format.

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