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

[Alan Modra]

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