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

noreply-nasm at gorcunov.org noreply-nasm at gorcunov.org
Thu Jul 4 07:57:07 PDT 2019


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

--- Comment #26 from TK Chia <u1049321969 at caramail.com> ---
Hello hpa,

To bridge the difference between my "old" relocation system and your proposed
relocation system, I suggest to add two relocations ---

R_386_FA16 : 48 : word16 : A + flat(S)
R_386_FA32 : 49 : word32 : A + flat(S)

--- and to somewhat redefine your proposed relocations:

R_386_SEG16 : 45 : word16 : A + ((flat(S) + B) >> 4)
R_386_SUBFA16 : 46 : word16 : A - flat(S)
R_386_SUBFA32 : 47 : word32 : A - flat(S)

I hope to try implementing these in binutils-ia16 some time.

flat(S), the "flat address" of S, can be defined differently according to the
relocation regime in use --- which may be configured through linker options or
by other means.

(1)
Under the new relocation system, the virtual address of a symbol S is the same
as its flat address space address.

flat(S) = S simply, and R_386_{16, 32} have the same effect as R_386_FA{16, 32}
respectively.

(2)
Under my old relocation system, the virtual address of a symbol S corresponds
to S's offset within its default segment.

flat(S) is defined to be the ELF "physical address" (the LMA in linker scripts)
of the symbol S, relative to some "base execution address" B.  flat(S) can be
determined at link time, but B is only known at run time.

An R_386_16 with symbol "foo" should then be equivalent to an R_386_FA16 with
"foo" followed by an R_386_SUBFA16 with "foo!".

Thank you!

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


More information about the Nasm-bugs mailing list