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

noreply-nasm at gorcunov.org noreply-nasm at gorcunov.org
Sun Aug 4 07:54:35 PDT 2019


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

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

> Things like .data.str1 used for merging strings.
> It gets really ugly for far segments.

I _think_ the `.data.str1' case can be handled by writing the linker script in
the right way.

As for far code/data segments:

(1) on the gas side, my code currently maps the section names `.whatever' and
`.whatever$' to the auxiliary section name `.whatever!'; and

(2) on the gcc side, I just altered the placement of far variables
(https://github.com/tkchia/gcc-ia16/commit/f60fd98484077aff3e1ce68bae8d0b760c7de2a7)
so that they are placed (by default) in `...$'-named sections.

E.g. the code

        static int __far x, y, z;

now compiles to

        .global x
        .section        .fardata.bar.c.44370$,"aw", at progbits
        .p2align        1
        .type   x, @object
        .size   x, 2
x:
        .skip   2,0
        .global y
        .p2align        1
        .type   y, @object
        .size   y, 2
y:
        .skip   2,0
        .global z
        .p2align        1
        .type   z, @object
        .size   z, 2
z:
        .skip   2,0

This should ultimately allow the linker script SORT_BY_NAME (...) trick to
place all the auxiliary symbols for far variables in the right places.

There is still a fair amount of work to do on the toolchain, though --- and, of
course, on nasm --- before they can usefully build programs under the segelf
ABI.

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