Quo vadis, thunk? (Was: Re: [PATCH/RFA] PR target/16665: SH thunk with -fPIC (fwd))

[Joern Rennecke <joern dot rennecke at superh dot com>]

Forwarded message:
> From renneckej  Sun Aug  1 04:57:49 2004
> Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm
> Precedence: bulk
> List-Unsubscribe: <mailto:gcc-patches-unsubscribe-joern.rennecke=superh.com@gcc.gnu.org>
> List-Archive: <http://gcc.gnu.org/ml/gcc-patches/>
> List-Post: <mailto:gcc-patches@gcc.gnu.org>
> List-Help: <mailto:gcc-patches-help@gcc.gnu.org>
> Sender: gcc-patches-owner@gcc.gnu.org
> Delivered-To: mailing list gcc-patches@gcc.gnu.org
> Subject: Re: [PATCH/RFA] PR target/16665: SH thunk with -fPIC
> To: kkojima@rr.iij4u.or.jp (Kaz Kojima)
> Date: Sun, 1 Aug 2004 04:54:44 +0100 (BST)
> Cc: gcc-patches@gcc.gnu.org
> MIME-Version: 1.0
> Content-Type: text/plain; charset=us-ascii
> Content-Transfer-Encoding: 7bit
> Message-Id: <20040801035444.B85322262D@meolyon.local>
> From: amylaar@spamcop.net (Joern Rennecke)
> X-OriginalArrivalTime: 01 Aug 2004 03:56:33.0300 (UTC) FILETIME=[88CC7540:01C4777B]
> 
> > 2004-07-31  Kaz Kojima  <kkojima@gcc.gnu.org>
> > 
> > 	PR target/16665
> > 	* config/sh/sh.c (sh_output_mi_thunk): Load GOT to the PIC
> > 	register temporary for PIC case.  Use one more intermediate
> > 	scrach register to load an UNSPEC_GOTOFF expression for
> > 	SHmedia PIC case.
> 
> We don't actually need the got, all we need is a pc-relative jump.
> For arbirtary offsets than can be done with a mov.l / braf combination.
> 
> If the thunks were actually emitted together with the function, we could
> even use just a bra, thus making the thunks even smaller and faster.
> 
> However, cp/method.c:make_thunk is self-contradicting in this regard.
> 
> There is a comment
> 
>   /* All thunks must be created before FUNCTION is actually emitted;
>      the ABI requires that all thunks be emitted together with the
>      function to which they transfer control.  */
> 
> But later it says:
> 
>   if (flag_weak)
>     comdat_linkage (thunk);
> 
> which turns the thunk into DECL_ONE_ONLY.  If the thunked-to function is
> not DECL_ONE_ONLY, the thunks end up in a different section than the function,
> and the linker can pull them arbitrarily far apart.
> 
> Is this a bug, or is the comment wrong?


I see that you wrote the comment in cp/method.c .  Is target port supposed
to be able to rely on the thunk being emitted together with the function
that is being thunked to?

> FWIW, I have found that when I force the thunk to agree with the function
> in use_thunk, bra works.  I've done this with a special thunk sibcall pattern
> that wraps the symbol_ref into an unspec, to prevent accidental matches.

I basically put it there because there was some other related code that
needed attention before - it makes the section agree if both function and
thunk are DECL_ONE_ONLY.  OTOH, I think DECL_ONE_ONLY should agree from
the start, so make_thunk might be a better place to implement this.