[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