On Thu, Nov 13, 2014 at 8:33 AM, Michael Matz <m...@suse.de> wrote: > 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
That is correct. > 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. @GOTPLT will create a PLT entry, but it doesn't mean PLT entry will be used. Only @PLTOFF will use PLT entry. Linker should be smart enough to use only one GOT slot, regardless if @GOTPLT or @GOT is used to take function address and call via PLT. However, if @GOTPLT is used without @PLT, a PLT entry will be created and unused. I'd like to propose 1. Update psABI to remove R_X86_64_GOTPLT64. 2. Fix assembler to take @GOTPLT for backward compatibility, 3. Make sure that linker uses one GOT slot for @GOT and @PLTOFF. > 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. > The reason I am asking about it is I'd like to finish the large model support in binutils and GCC. I have filed a couple bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63833 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=63842 https://sourceware.org/bugzilla/show_bug.cgi?id=17592 https://sourceware.org/bugzilla/show_bug.cgi?id=17593 I will fix all of them and verify that large model works correctly. -- H.J.