Re: [PowerPC 64]r12 is not updated to GEP when control transferred from virtual thunk function .

[Alan Modra <amodra at gmail dot com>]

On Mon, May 20, 2019 at 02:55:33AM -0500, Segher Boessenkool wrote:
> On Mon, May 20, 2019 at 04:19:54PM +0930, Alan Modra wrote:
> > On Thu, May 16, 2019 at 05:52:42PM -0500, Segher Boessenkool wrote:
> > > Hi Umesh,
> > > 
> > > On Thu, May 16, 2019 at 06:12:48PM +0530, Umesh Kalappa wrote:
> > > > We are very new to Power abi and we are thinking to handle this case
> > > > in loader  like  go through the  relocations like R_PPC64_REL24 and
> > > > found symbol has the localentry ,then compute the delta (GEP - LEP )
> > > > and patch the caller address like (sym.value - delta).
> > > 
> > > I wonder if you have found a bug in the compiler after all.  Most things
> > > are supposed to work without the linker/loader having to do special
> > > things; e.g. using the global entry point should always work, using the
> > > local entry point is just an optimisation.
> > 
> > That isn't true for direct calls.  If using the global entry point,
> > the linker must provide stub code to load up r12 with the global entry
> > address and modify the nop after the bl.  The linker must also adjust
> > calls using the local entry point; the call instruction (and
> > relocation) specify the function symbol not the function plus local
> > entry offset.
> > 
> > So I don't think there is any compiler bug here, just a broken kernel
> > module loader.  Incidentally, if thunks are broken then it's very
> > likely local function calls are broken too.
> 
> The ABI says
> 
> "When a linker causes control to transfer to a global entry point, it
> must insert a glue code sequence that loads r12 with the global
> entry-point address. Code at the global entry point can assume that
> register r12 points to the GEP."
> 
> But in the testcase the jump *already* was to the global entry point:

So?  We never add the local entry offset to the call assembly.
Compile this to assembly (without -fPIC) and note "bl print" in main.

#include <stdio.h>

void __attribute__ ((noclone, noinline))
print (const char *str)
{
  puts (str);
}

int
main ()
{
  print ("Hello");
  return 0;
}

Now if the thunk code produced a branch to a local label that *wasn't*
a function symbol, I'd agree that gcc was wrong.

-- 
Alan Modra
Australia Development Lab, IBM