Bug 17699

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.

Please attach the .o file containing the original relocation.

Created attachment 8004 [details]
object that results in bad reloc in elf

Pinpointed to originate from ./gcc-4.9.2/libstdc++-v3/libsupc++/eh_globals.cc. Object file attached.

The minimal way to reproduce this seems to be:

-- test.cc
struct foo { int a; };

namespace
{
  struct foo *get_global() throw()
  {
    static __thread struct foo global;
    return &global;
  }
} // anonymous namespace
--

And compile .so with:
g++ -fPIC test.cc -shared -o test.so

Without -fPIC it looks better.

Even more minimal test case in C:
 int bar() { static __thread int foo; return foo; }

Notable that this does not cause the same issue:
 __thread int __attribute__((__visibility__("hidden"))) foo; int *bar() { return &foo; }

I can't find any support for the claims made in Comment #1.

In all ABIs using the IA-64 TLS model, the DTPMOD relocation is defined as resolving to the index of the load module where the *referenced symbol* is defined. Thus, the r_sym field of the relocation is relevant, and is used by the dynamic linker to determine what load module index to insert into the GOT entry. In the case of a reference to a local symbol, the local symbol can be (and usually is) collapsed to a section symbol, and the dynamic loader resolves the relocation to the index of the current load module (which is where the local symbol is defined).

It appears that Gnu ld has adopted a convention where a 0 symbol index may also be used to refer to the current load module, but that convention is not described in the ABI, as far as I can determine, nor does the dynamic linker depend on it.

In my opinion, the musl dynamic linker was written to conform to one specific implementation (viz, the Gnu linker), and not to the specification.

Section symbols in the dynamic symbol table are not only perfectly valid, but are used frequently -- whether for TLS or not. They do not depend on the section table any more than any other symbol, since the value of a symbol in an executable is always a proper virtual address.

Can you cite any documentation that a non-STT_TLS symbol reference is permissible in a DTPMOD relocation?

> Can you cite any documentation that a non-STT_TLS symbol reference is
> permissible in a DTPMOD relocation?

The section symbol for an SHF_TLS section is effectively a TLS symbol, and must be treated as such.

See, for example, PR 16773, where a compiler-generated relocation references the .tdata section symbol rather than a local symbol in the section.