On Sun, 2015-10-04 at 22:16 -0400, Rich Felker wrote: > This is FDPIC-specific. Because there is fundamentally no way for a > function to find its own GOT (it has one GOT for each process using > the code containing the function), its GOT address has to be a > (hidden) argument to the function which arrives in r12. > > For calls via the PLT, r12 contains the PLT entry's (i.e. the calling > module's) GOT pointer at the time of the call, and the PLT thunk > replaces it with the callee's GOT pointer (loaded from the function > descriptor) before jumping to the callee code. There is fundamentally > nowhere the PLT thunk could store the old value of r12 and arrange for > it to be restored at return time, so using a PLT forces r12 to be > call-clobbered. > > (Note that in the special case where the PLT is bypassed because the > callee is defined in the same module and bound at link-time, the GOT > value loaded by the caller is the right GOT value for the callee > automatically.) > > If we didn't care about being able to do PLT calls, there's no > fundamental reason r12 has to be call-clobbered, but it still makes a > lot more sense. Getting back the value of r12 you passed when making a > function call is rarely useful except in the case where the caller > knows the function is defined in the same module (so it can keep using > r12 as its own GOT pointer after the call). > > BTW the reason I'm spending time explaining this now is that it's > something we should optimize after the FDPIC patch goes in: I think > the r12-related spills/reload could be made a lot more efficient.
This will be a separate point then, after the initial FDPIC stuff is in. Maybe also related: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=12306 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=54019 Cheers, Oleg
