This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] SH FDPIC backend support
- From: Oleg Endo <oleg dot endo at t-online dot de>
- To: Rich Felker <dalias at libc dot org>
- Cc: gcc-patches at gcc dot gnu dot org, Kaz Kojima <kkojima at rr dot iij4u dot or dot jp>
- Date: Mon, 05 Oct 2015 20:53:19 +0900
- Subject: Re: [PATCH] SH FDPIC backend support
- Authentication-results: sourceware.org; auth=none
- References: <20151001213559 dot GA2442 at brightrain dot aerifal dot cx> <1443738987 dot 2031 dot 136 dot camel at t-online dot de> <20151001233910 dot GN8645 at brightrain dot aerifal dot cx> <20151002013017 dot GO8645 at brightrain dot aerifal dot cx> <20151003191216 dot GD8645 at brightrain dot aerifal dot cx> <20151003223434 dot GE8645 at brightrain dot aerifal dot cx> <1443935442 dot 2031 dot 544 dot camel at t-online dot de> <20151005021647 dot GH8645 at brightrain dot aerifal dot cx>
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