Re: Question re: Thunks (was Re: [PATCH] - Fix PR 21956 and PR 22003)

[Dale Johannesen <dalej at apple dot com>]

On Aug 5, 2005, at 2:26 PM, Mark Mitchell wrote:

> Richard Henderson wrote:
> > I'll agree that it's possible to put them in to different sections
> > iff it's possible to properly predict this from the backend.  We
> > can then use indirect branches when necessary to perform the jump.
> > That said, I see no reason not to always put the thunks in the
> > same section.  We really should always choose a matched set of
> > functions when resolving symbols.
>
> Thunks should always be in the same section as their targets.  In 
> fact, if we were smarter, some of our thunks would not end with jumps 
> at all; they would fall through into the main function, if there was 
> only one thunk, or be alternate entry points.

This would not work on Darwin; the linker does not support multiple 
entry points, and can
move the thunk away from the main function.

I can't see a good reason to force both to be in the same section if 
profile info shows the
thunk is lightly executed and the main function isn't, for example.  
You really don't want
unexecuted code cluttering up your I-cache.

> It is an invariant of the ABI design that all thunks are emitted in 
> the same object file as the target function.
>
> If we're depending on gnu.linkonce sections, life gets a little 
> unpleasant, in the case, of, say, a virtual function that is a 
> template.  We need some way to say that both the thunks and the 
> targets are linkonce, but we have no way, so far as I know, of putting 
> them in the same linkonce section, with our current machinery.  (I 
> think the linker would handle it, but I don't think we know how to do 
> it in varasm.c.)
>
> With COMDAT, this should definitely work, but again, we probably need 
> to make varasm.c know that the thunk goes in the same COMDAT group as 
> the target.  (And, we need to figure out why Julian Brown's patch to 
> not make COMDAT things weak doesn't work for people.)
>
> --
> Mark Mitchell
> CodeSourcery, LLC
> mark@codesourcery.com
> (916) 791-8304