This is the mail archive of the binutils@sourceware.org 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: [RFC] [gold] Simplify relocation strategy logic


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


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