[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 #40 from TK Chia <u1049321969 at caramail.com> ---
Hello hpa,

> The problem with that notion is that for external far symbols to work, you
> *have* to be able to obtain both the segment base and segment offset for
> that symbol, and they are two separate values. Furthermore, they are a
> property of the symbol itself, not a property of the location of the symbol.

I am not sure that this is a major problem, even we if (say) we assume that we
will be putting together a relocatable ELF file before converting it to some
other format.

This is because "[e]very symbol entry is `defined' in relation to some
section", namely its st_shndx.

So the output ELF section of a symbol is very much a property of the symbol
itself --- in the same way as the symbol's size (st_size) is.

(Admittedly, though, there is no straightforward mapping between ELF sections
and ELF _segments_ as given by program headers.  As far as I can tell, only ELF
segments know about physical (or load) addresses; ELF sections do not know
about them.)

Anyway, the main problem I encountered while implementing your most recent
segelf proposal (https://bugzilla.nasm.us/show_bug.cgi?id=3392533#c21) is that,
as I said, magically creating a symbol "foo!" in a section ".rodata!", given a
symbol "foo" in section ".rodata", turned out to be surprisingly difficult ---
whether at the GCC, GNU as, or GNU ld layer.

If the additional relocations are on the _same_ symbol, e.g. if we have two or
more relocations for "foo" stacked at the same place, the implementation should
be easier.

> 1. Link with --emit-relocs and postprocess (i.e. an elf2exe program). The
> "reloc" program in the Linux kernel contains all the ELF-parsing code you
> would need and should be easy enough to modify to produce MZ exe files; most
> of it is taking code out.

Incidentally, what I am currently doing in Binutils is to add hooks (as part of
a "linker emulation") which magically tacks new .msdos_mz_reloc.* sections onto
the input modules, and then fills them in when it is time to output everything.

But I think a post-processor program, as you suggested, should also be able to
do the trick.

(GCC has a provision for adding a post-link pass --- it is not really
documented, but it is there, and DJGPP already uses it.  There is also a
provision for adding a post-assembly pass to munge a .o files before they go to
the linker.)

Thank you!

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