Home Original page

[RFC] [gold] Simplify relocation strategy logic

Richard Sandiford richard.sandiford@linaro.org
Mon Mar 14 10:47:00 GMT 2011 
Cary Coutant <ccoutant@google.com> writes:
>      case elfcpp::R_X86_64_GOT64:
>      case elfcpp::R_X86_64_GOT32:
> +      // Absolute in GOT.
> +      return Symbol::ABSOLUTE_REF | Symbol::GOT_REF;
>      case elfcpp::R_X86_64_GOTPCREL64:
>      case elfcpp::R_X86_64_GOTPCREL:
> +      // PC-Relative in GOT.
> +      return Symbol::RELATIVE_REF | Symbol::GOT_REF;
> +
>      case elfcpp::R_X86_64_GOTPLT64:
> -      // Absolute in GOT.
> -      return Symbol::ABSOLUTE_REF;
> +      return Symbol::ABSOLUTE_REF | Symbol::GOT_REF;

I don't believe this is correct.  ABSOLUTE_REF is defined as:

    // A reference to the symbol's absolute address.  This includes
    // references that cause an absolute address to be stored in the GOT.
    ABSOLUTE_REF = 1,

and the final symbol reference (by the GOT entry) is absolute
in all these cases.  ("Absolute in GOT" was supposed to mean
"an absolute reference _in_ the global offset table", not "to".)
Whether the reference to the GOT entry itself is absolute, relative
to the GP, or relative to the PC, isn't modelled by these flags.

Does the patch rely on this, or was it just something you noticed
by inspection?

Richard
More information about the Binutils mailing list