Project

General

Profile

Bug #1879

TLS causes unprocessable relocations in DWARF sections

Added by Rich Lowe almost 9 years ago. Updated over 2 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
-
Start date:
2011-12-11
Due date:
% Done:

0%

Estimated time:
Difficulty:
Medium
Tags:
needs-triage
Gerrit CR:

Description

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.


Related issues

Related to illumos gate - Feature #2004: newer gcc, and sanity, would benefit from a newer libdwarfResolved2012-01-20

Actions

History

#1

Updated by Rich Lowe almost 9 years ago

Option #2 would require ctfconvert supporting multiple compilation units (I picked a bad test case to see whether it worked).

#3

Updated by Rich Lowe about 8 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).

Also available in: Atom PDF