GOLD handling of weak symbols (including x86 vs. ARM)

[Cary Coutant]

> ===================================================================
> --- gold/i386.cc        2010-11-09 08:21:13.000000000 +0000
> +++ gold/i386.cc        2010-11-09 08:21:23.000000000 +0000
> -// Return whether we need to make a PLT entry for a relocation of a
> -// given type against a STT_GNU_IFUNC symbol.
> +// Get the Reference_flags for a particular relocation.
>
> -bool
> -Target_i386::Scan::reloc_needs_plt_for_ifunc(Sized_relobj<32, false>* object,
> -                                            unsigned int r_type)
> +int
> +Target_i386::Scan::get_reference_flags(unsigned int r_type)
>  {
>   switch (r_type)
>     {
>     case elfcpp::R_386_NONE:
>     case elfcpp::R_386_GNU_VTINHERIT:
>     case elfcpp::R_386_GNU_VTENTRY:
> -      return false;
> +    case elfcpp::R_386_GOTPC:
> +      // No symbol reference.
> +      return 0;

> +// Return whether we need to make a PLT entry for a relocation of a
> +// given type against a STT_GNU_IFUNC symbol.
> +
> +bool
> +Target_i386::Scan::reloc_needs_plt_for_ifunc(Sized_relobj<32, false>* object,
> +                                            unsigned int r_type)
> +{
> +  int flags = get_reference_flags(r_type);
> +  if (flags & Symbol::TLS_REF)
> +    gold_error(_("%s: unsupported TLS reloc %u for IFUNC symbol"),
> +               object->name().c_str(), r_type);
> +  return flags != 0;
> +}

It looks like reloc_needs_plt_for_ifunc will now return a different
answer for R_386_GOTPC than it did before. Was that a bug before?

This function could probably use a comment explaining why (flags != 0)
is the right answer.

-cary