Hi, On Thu, 13 Nov 2014, H.J. Lu wrote:
> x86-64 psABI has > > name@GOT: specifies the offset to the GOT entry for the symbol name > from the base of the GOT. > > name@GOTPLT: specifies the offset to the GOT entry for the symbol name > from the base of the GOT, implying that there is a corresponding PLT entry. > > But GCC never generates name@GOTPLT and assembler fails to assemble > it: I've added the implementation for the large model, but only dimly remember how it got added to the ABI in the first place. The additional effect of using that reloc was supposed to be that the GOT slot was to be placed into .got.plt, and this might hint at the reasoning for this reloc: If you take the address of a function and call it, you need both a GOT slot and a PLT entry (where the existence of GOT slot is implied by the PLT of course). Now, if you use the normal @GOT64 reloc for the address-taking operation that would create a slot in .got. For the call instruction you'd use @PLT (or variants thereof, like PLTOFF), which creates the PLT slot _and_ a slot in .got.plt. So, now we've ended up with two GOT slots for the same symbol, where one should be enough (the address taking operation can just as well use the slot in .got.plt). So if the compiler would emit @GOTPLT64 instead of @GOT64 for all address references to symbols where it knows that it's a function it could save one GOT slot. So, I think it was supposed to be a small optimization hint. But it never was used in the compiler ... > [hjl@gnu-6 pr17598]$ cat x.S > movabs $foo@GOTPLT,%rax > [hjl@gnu-6 pr17598]$ gcc -c x.S > x.S: Assembler messages: > x.S:1: Error: relocated field and relocation type differ in signedness ... and now seems to have bit-rotted. > [hjl@gnu-6 pr17598]$ > > It certainly isn't needed on data symbols. I couldn't find any possible > usage for this relocation on function symbols. The longer I think about it the more I'm sure it's the above optional optimization mean. Ciao, Michael.
