[Bug gold/17699] incorrect R_386_TLS_DTPMOD32 relocation

[bugdal at aerifal dot cx]

https://sourceware.org/bugzilla/show_bug.cgi?id=17699

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #1 from Rich Felker <bugdal at aerifal dot cx> ---
Some follow-up regarding my (Rich Felker) reasoning for why the reloc gold is
producing is wrong:

1. The existing convention for producing a DTPMOD reloc for "this DSO itself"
is to omit the symbol reference. This is what gold does on other archs and what
BFD ld has always done.

2. Semantically, a symbol pointing to a section does not even make sense as the
target for a TLS relocation. The targeted symbol for such a reloc must be TLS
type (STT_TLS). Simply the fact that the targeted section happens to be a
TLS-related section does not make it a TLS symbol. If anything, by a principle
of least surprise, such a symbol should resolve to the TLS image (but for BSS
that doesn't even exist) rather than the resulting thread-local storage.

3. In my opinion, STT_SECTION symbols are not valid in the dynamic symbol table
at all. Sections are not meaningful at load/execution time, and it's arguably
even valid to strip the section headers if you really want to.

I'm not clear on why glibc's dynamic linker accepts this relocation; probably
it's simply a consequence of an implementation detail of the order in which
operations are performed. But musl's dynamic linker is not accepting it, and I
don't see any logically consistent way to accept it short of hacks to just
ignore the referenced symbol and treat it as a null symbol reference, so I'd
much rather see this fixed in gold than work on hacks to work around it.

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