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
