This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[gold RFC] Do not generate dynamic reloc for unresolved TLS symbol


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
regardless.

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
something.

(Before I commit, I'll add a test case for --warn-unresolved-symbols,
with unresolved TLS and non-TLS symbols.)

-cary


diff --git a/gold/symtab.cc b/gold/symtab.cc
index c433018..341e0fd 100644
--- a/gold/symtab.cc
+++ b/gold/symtab.cc
@@ -462,11 +462,11 @@ Symbol::final_value_is_known() const
        return true;
     }

-  // 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]