This is the mail archive of the
mailing list for the binutils project.
Re: [gold RFC] Do not generate dynamic reloc for unresolved TLS symbol
- From: Alan Modra <amodra at gmail dot com>
- To: Cary Coutant <ccoutant at google dot com>
- Cc: Binutils <binutils at sourceware dot org>, Ian Lance Taylor <iant at google 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: Fri, 19 Dec 2014 09:14:58 +1030
- Subject: Re: [gold RFC] Do not generate dynamic reloc for unresolved TLS symbol
- Authentication-results: sourceware.org; auth=none
- References: <CAHACq4oi4UT7LLv-vz5+ocpkPU8zwtyOQ8Gas_S3WdB_7WgN2w at mail dot gmail dot com>
On Thu, Dec 18, 2014 at 10:50:07AM -0800, Cary Coutant wrote:
> --- 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.
As the comment says it "could reasonably be the case for a weak
undefined symbol". If the reference to a weak symbol is in PIC, then
you can emit dynamic relocs and have an executable do something
reasonable based on whether the symbol is defined at runtime.
Australia Development Lab, IBM