This is the mail archive of the 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]

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

On Thu, Dec 18, 2014 at 10:50:07AM -0800, Cary Coutant wrote:
> --- a/gold/
> +++ b/gold/
> @@ -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

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