[gold RFC] Do not generate dynamic reloc for unresolved TLS symbol
Thu Dec 18 18:50:00 GMT 2014
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.
More information about the Binutils