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

[noreply-nasm at gorcunov.org]

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

TK Chia <u1049321969 at caramail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |u1049321969 at caramail.com

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

Yes, I am working on a fork (https://github.com/tkchia/build-ia16 etc.) of
Jenner et al.'s venerable gcc-ia16 toolchain.

For the Binutils portion of the toolchain, what I have done to add MZ
relocations support is rather hacky and simplistic:

(*) I added a R_386_RELSEG16 relocation type, which says to plug in the
    segment which a symbol belongs to relative to the program start.  To do
    this, I sort of cannibalized Binutils' distinction between LMAs and VMAs
    in linker scripts.

    The linker script will specify overlapping LMAs for sections which
    should be treated as separate IA-16 segments.  E.g. it may say that the
    .text, .data, and .fardata.0 output sections will reside at different
    VMAs, but have the same LMA of 0.

    Then at link time, an R_386_RELSEG16's value is computed as the
    paragraph displacement of the symbol's LMA from its VMA, minus the VMA
    of the end of an "MS-DOS header" output section (.msdos_mz_hdr) if it
    exists.  (I hope that made sense.)

(*) I also implemented a R_386_SEGMENT16 relocation type, which says to plug
    in the actual segment which a symbol belongs to --- this will be the
    equivalent of the "seg" operator.

    In the Binutils assembler, I arrange for an R_386_SEGMENT16 to be
    automagically split into two R_386_RELSEG16's --- one at the actual
    place to be relocated, and another in an "MZ relocation entry" output
    section which should ultimately go into .msdos_mz_hdr.

    (I am still not very satisfied with this arrangement --- I hope to
    improve the toolchain so that it can directly output and handle
    R_386_SEGMENT16 relocations in object files.)

I am still not very satisfied with the above arrangement myself --- I hope,
before getting my Binutils patches upstream, to at least improve them so
that they can directly output and handle R_386_SEGMENT16 relocations in
object files.

In addition, in their present form they probably do not address some corner
cases (e.g. "wrt") which hpa's proposal touches on.

Thank you!

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