This is the mail archive of the
binutils@sourceware.org
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.
--
Alan Modra
Australia Development Lab, IBM