This is the mail archive of the
mailing list for the binutils project.
[gold RFC] Do not generate dynamic reloc for unresolved TLS symbol
- From: Cary Coutant <ccoutant at google dot com>
- To: Binutils <binutils at sourceware dot org>, Ian Lance Taylor <iant at google dot com>, Alan Modra <amodra at gmail dot com>, Jing Yu <jingyu at google dot com>, Han Shen <shenhan at google dot com>, Doug Kwan <dougkwan at google dot com>, David Miller <davem at davemloft dot net>
- Date: Thu, 18 Dec 2014 10:50:07 -0800
- Subject: [gold RFC] Do not generate dynamic reloc for unresolved TLS symbol
- Authentication-results: sourceware.org; auth=none
I have an internal bug report where they're trying to link an object
file with an unresolved TLS symbol (using --warn-unresolved-symbols).
For non-TLS symbols, when linking an executable, we statically resolve
the symbols to 0 and do not generate a dynamic relocation (this is
handled in Symbol::needs_dynamic_reloc()). But for TLS symbols, we do
not call this function, and we generate the dynamic relocation
I believe that the right fix is to change
Symbol::final_value_is_known() to return true for undefined symbols
when the output is executable. We would then treat the relocation as
one that could be optimized to the LE model, and would statically
resolve the symbol to 0 with no dynamic relocation. This would match
Gnu ld behavior.
The following patch passes all tests on x86_64, but I wanted to give
you all a chance to comment on it before I commit, since the change
has a broader effect than just TLS symbols, and I might have missed
(Before I commit, I'll add a test case for --warn-unresolved-symbols,
with unresolved TLS and non-TLS symbols.)
diff --git a/gold/symtab.cc b/gold/symtab.cc
index c433018..341e0fd 100644
@@ -462,11 +462,11 @@ Symbol::final_value_is_known() const
- // If the symbol is undefined, then whether the final value is known
- // depends on whether we are doing a static link. If we are doing a
- // dynamic link, then the final value could be filled in at runtime.
- // This could reasonably be the case for a weak undefined symbol.
- return parameters->doing_static_link();
+ // The symbol is unresolved. If we are building an executable,
+ // unresolved symbols are statically resolved to 0, so the final value
+ // is known. If we're doing a shared link, they can be resolved
+ // dynamically, so the final values are not known.
+ return parameters->options().output_is_executable();
// Return the output section where this symbol is defined.