TLS causes unprocessable relocations in DWARF sections
The use of TLS in certain ON libraries (libc, libses, libsmp) causes relocations in the DWARF debug information which cannot be processed reliably in the object file.
These are R_AMD64_DTPOFF32 reloctations which end up being relative to the (eventual) .tls section. These are resolved when the final object is linked, but in intermediate objects are not statically processable by libdwarf.
The libdwarf we presently use flags this with the "achtung!" message from simmonmt, newer versions of libdwarf which process relocations silently ignore the bad relocation. The newest versions of libdwarf error when encountering a relocation which cannot be processed.
There are two ways to work around this:
1. If libdwarf cannot deal with an object, and it cannot do so because of an unprocessable relocation, issue a warning and create an empty CTF container. This is not dissimilar to the current behaviour
2. Rather than ctfconverting each object file, and then ctf merging them into the shared object, ctf convert only the shared object. This works (I think), but loses us the property that we notice, and error, if any object built from C sources does not contain debug information.
Neither option is particularly good. Unfortunately, we cannot merely cease to use __thread variables, as the use in libc became part of the API with strndupa(). We're stuck with it.
Updated by Igor Pashev over 9 years ago
Updated by Rich Lowe over 9 years ago
Yes, that's precisely the issue (newer libdwarf bails out, that's why we're not using a newer libdwarf...). My understanding, though, is that the relocation can't really be resolved until the link editor runs (at which point it does in fact resolve it).