[RFC] [gold] Simplify relocation strategy logic
Richard Sandiford
richard.sandiford@linaro.org
Mon Mar 14 16:28:00 GMT 2011
More information about the Binutils mailing list
Mon Mar 14 16:28:00 GMT 2011
- Previous message (by thread): [RFC] [gold] Simplify relocation strategy logic
- Next message (by thread): [RFC] [gold] Simplify relocation strategy logic
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Cary Coutant <ccoutant@google.com> writes: >> 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? > > My understanding of the ABI is that R_X86_64_GOTPCREL is a pc-relative > relocation to the GOT entry, and R_X86_64_GOTPLT64 is an absolute > reference to a GOT entry. In both cases, I believe the GOT entry > itself is expected to contain an absolute address. Right. > I rely on these flags modeling the reference to the GOT entry, not the > GOT entry itself, In that case, you're changing the meaning of the flags, so I think you'll need to adjust all other ports as well the comment. The current code really was written to the current definition of ABSOLUTE_REF. Richard
- Previous message (by thread): [RFC] [gold] Simplify relocation strategy logic
- Next message (by thread): [RFC] [gold] Simplify relocation strategy logic
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
More information about the Binutils mailing list