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

Actually, I think the best place to implement a "foo!" system in a gcc -> ...
-> ld construction pipeline would be as a separate post-processor for .o files.
 Such a post-processor will be free to mess with a .o's relocations _and_
symbol table _and_ section table together at the same time.

I believe that such an implementation will stand the highest chance of not
weirding out in corner cases, even if it is kind of silly to have to do this.

> binutils support is a prerequisite, though, exactly because without
> especially ld, nm, and readelf it is very hard to do this work. Hence
> starting with that.

I believe I have already added hjl's patches for the R_386_SUB16 etc.
relocations to my Binutils fork, including the main "binutils-ia16-tkchia"
branch).  I will see if I can get around to adding the R_386_RELATIVESEG
patches   to the linker, and maybe add some knowledge of R_386_SUB16 and
R_386_SUB32 to the assembler.

> That being said, did you look at the macros I posted?  They hide a *lot* of
> the rigamarole.

Yes, I have done so.  I think the issue is less of "is the output assembly is
human-readable?" but more of "will the output be correct in, say, >= 99% of the
cases that worked correctly before?".

In particular, I found during my earlier attempt
(https://gist.github.com/tkchia/746ba8c5ea601e1c5c3ad18ade5f8638) that in GCC's
internals it is hard to get an answer to the question "what is the name of the
section this `foo' function is defined in?", because the section information is
scattered in at least 3 places.

Thank you!

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