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

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

[Umesh Kalappa]

Hi All,

We have the situation ,where the R12 is pointing to Thunk GEP ,not the
current function  like

       .size   _ZN12Intermediate1vEv,.-_ZN12Intermediate1vEv
        .set    .LTHUNK0,_ZN12Intermediate1vEv
        .align 2
        .globl _ZThn8_N12Intermediate1vEv
        .type   _ZThn8_N12Intermediate1vEv, @function
_ZThn8_N12Intermediate1vEv:
.LFB27:
        .file 2 "/home/vkumar1/tmp/64_bit/qsp_ppc/gnu/dkmcxx/lib.h"
        .loc 2 13 16
        .cfi_startproc
.LCF2:
0:      addis 2,12,.TOC.-.LCF2@ha
        addi 2,2,.TOC.-.LCF2@l
        .localentry     _ZThn8_N12Intermediate1vEv,.-_ZThn8_N12Intermediate1vEv
        addi 3,3,-8
        b .LTHUNK0
        .cfi_endproc
.LFE27:
        .size   _ZThn8_N12Intermediate1vEv,.-_ZThn8_N12Intermediate1vEv
        .section        ".toc","aw"
        .set .LC1,.LC0

.section        ".text"
        .align 2
        .globl _ZN12Intermediate1vEv
        .type   _ZN12Intermediate1vEv, @function
_ZN12Intermediate1vEv:
.LFB25:
        .loc 1 7 23
        .cfi_startproc
.LCF1:
0:      addis 2,12,.TOC.-.LCF1@ha
        addi 2,2,.TOC.-.LCF1@l
        .localentry     _ZN12Intermediate1vEv,.-_ZN12Intermediate1vEv
        mflr 0
        std 0,16(1)
        std 31,-8(1)
        stdu 1,-64(1)

like above the control  from "_ZThn8_N12Intermediate1vEv" (support
function for this pointer update)  is transferred
"_ZN12Intermediate1vEv" by b  inst (where its not updating the r12)
and in the beginning  of   "_ZN12Intermediate1vEv" we are loading the
toc base from r12 (which is incorrect ) ,we are investigating the
issue and one way to fix the issue is that make THUNK to update the
r12 ,the cal like bctrl  or  load the r12 with the function address in
the _ZN12Intermediate1vEv prologue code .

But before we go ahead ,please share your thoughts or shed some lights
on the same .

Thank you
~Umesh

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

[Eric Botcazou]

> like above the control  from "_ZThn8_N12Intermediate1vEv" (support
> function for this pointer update)  is transferred
> "_ZN12Intermediate1vEv" by b  inst (where its not updating the r12)
> and in the beginning  of   "_ZN12Intermediate1vEv" we are loading the
> toc base from r12 (which is incorrect ) ,we are investigating the
> issue and one way to fix the issue is that make THUNK to update the
> r12 ,the cal like bctrl  or  load the r12 with the function address in
> the _ZN12Intermediate1vEv prologue code .

Is that on VxWorks in kernel mode?  If so, the loader doesn't abide by the 
ELFv2 ABI so the simple way out is to disable asm thunks altogether:

#undef TARGET_ASM_CAN_OUTPUT_MI_THUNK
#define TARGET_ASM_CAN_OUTPUT_MI_THUNK rs6000_can_output_mi_thunk

/* Return true if rs6000_output_mi_thunk would be able to output the
   assembler code for the thunk function specified by the arguments
   it is passed, and false otherwise.  */

static bool
rs6000_can_output_mi_thunk (const_tree, HOST_WIDE_INT, HOST_WIDE_INT,
			    const_tree)
{
  /* The only possible issue is for VxWorks in kernel mode.  */
  if (!TARGET_VXWORKS || TARGET_VXWORKS_RTP)
    return true;

  /* The loader neither creates the glue code sequence that loads r12 nor uses
     the local entry point for the sibcall's target in the ELFv2 ABI.  */
  return DEFAULT_ABI != ABI_ELFv2;
}

-- 
Eric Botcazou

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

[Umesh Kalappa]

Thank you Eric for the suggestion and say that we support in the  loader
part ,can you please point on elfv2 reference that says implementation for
this specific case.

~Umesh

On Wed, May 15, 2019, 21:35 Eric Botcazou <ebotcazou@adacore.com> wrote:

> > like above the control  from "_ZThn8_N12Intermediate1vEv" (support
> > function for this pointer update)  is transferred
> > "_ZN12Intermediate1vEv" by b  inst (where its not updating the r12)
> > and in the beginning  of   "_ZN12Intermediate1vEv" we are loading the
> > toc base from r12 (which is incorrect ) ,we are investigating the
> > issue and one way to fix the issue is that make THUNK to update the
> > r12 ,the cal like bctrl  or  load the r12 with the function address in
> > the _ZN12Intermediate1vEv prologue code .
>
> Is that on VxWorks in kernel mode?  If so, the loader doesn't abide by the
> ELFv2 ABI so the simple way out is to disable asm thunks altogether:
>
> #undef TARGET_ASM_CAN_OUTPUT_MI_THUNK
> #define TARGET_ASM_CAN_OUTPUT_MI_THUNK rs6000_can_output_mi_thunk
>
> /* Return true if rs6000_output_mi_thunk would be able to output the
>    assembler code for the thunk function specified by the arguments
>    it is passed, and false otherwise.  */
>
> static bool
> rs6000_can_output_mi_thunk (const_tree, HOST_WIDE_INT, HOST_WIDE_INT,
>                             const_tree)
> {
>   /* The only possible issue is for VxWorks in kernel mode.  */
>   if (!TARGET_VXWORKS || TARGET_VXWORKS_RTP)
>     return true;
>
>   /* The loader neither creates the glue code sequence that loads r12 nor
> uses
>      the local entry point for the sibcall's target in the ELFv2 ABI.  */
>   return DEFAULT_ABI != ABI_ELFv2;
> }
>
> --
> Eric Botcazou
>

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

[Eric Botcazou]

> Thank you Eric for the suggestion and say that we support in the  loader
> part ,can you please point on elfv2 reference that says implementation for
> this specific case.

I don't think there is a reference to this specific case in the ABI, only the 
general stuff about local and global entry points.  We have had this patch in 
our tree for some time and it works well, so let me submit it for inclusion in 
the official tree.

-- 
Eric Botcazou

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

[Segher Boessenkool]

Hi Umesh,

Please spell out "global entry point", almost everything and everyone does.

On Wed, May 15, 2019 at 08:57:29PM +0530, Umesh Kalappa wrote:

>         .set    .LTHUNK0,_ZN12Intermediate1vEv

> _ZThn8_N12Intermediate1vEv:
> .LCF2:
> 0:      addis 2,12,.TOC.-.LCF2@ha
>         addi 2,2,.TOC.-.LCF2@l
>         .localentry     _ZThn8_N12Intermediate1vEv,.-_ZThn8_N12Intermediate1vEv
>         b .LTHUNK0

> _ZN12Intermediate1vEv:
> .LCF1:
> 0:      addis 2,12,.TOC.-.LCF1@ha
>         addi 2,2,.TOC.-.LCF1@l

> like above the control  from "_ZThn8_N12Intermediate1vEv" (support
> function for this pointer update)  is transferred
> "_ZN12Intermediate1vEv" by b  inst (where its not updating the r12)
> and in the beginning  of   "_ZN12Intermediate1vEv" we are loading the
> toc base from r12 (which is incorrect ) ,we are investigating the
> issue and one way to fix the issue is that make THUNK to update the
> r12 ,the cal like bctrl  or  load the r12 with the function address in
> the _ZN12Intermediate1vEv prologue code .

The thunk should point to the local entry point instead, I guess?

Please open a PR, with compilable testcase, and other relevant info (if
you need some specific -mcpu= for example, or other flags, do mention
that!)  See https://gcc.gnu.org/bugs.html for more info.  Thanks!


Segher

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

[Segher Boessenkool]

On Wed, May 15, 2019 at 08:31:27PM +0200, Eric Botcazou wrote:
> > Thank you Eric for the suggestion and say that we support in the  loader
> > part ,can you please point on elfv2 reference that says implementation for
> > this specific case.
> 
> I don't think there is a reference to this specific case in the ABI, only the 
> general stuff about local and global entry points.

Yes, it is just a normal jump to a local function.

> We have had this patch in 
> our tree for some time and it works well, so let me submit it for inclusion in 
> the official tree.

Can't you get the loader fixed, instead?


Segher

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

[Umesh Kalappa]

>>Can't you get the loader fixed, instead?
Yes we are thinking the same ,question what should be loader semantics here
(update the prologue code to update r12 to Global Entry Point or Update R2
with toc base (that don't relay on the R12). )

~Umesh
On Thu, May 16, 2019, 05:22 Segher Boessenkool <segher@kernel.crashing.org>
wrote:

> On Wed, May 15, 2019 at 08:31:27PM +0200, Eric Botcazou wrote:
> > > Thank you Eric for the suggestion and say that we support in the
> loader
> > > part ,can you please point on elfv2 reference that says implementation
> for
> > > this specific case.
> >
> > I don't think there is a reference to this specific case in the ABI,
> only the
> > general stuff about local and global entry points.
>
> Yes, it is just a normal jump to a local function.
>
> > We have had this patch in
> > our tree for some time and it works well, so let me submit it for
> inclusion in
> > the official tree.
>
> Can't you get the loader fixed, instead?
>
>
> Segher
>

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

[Umesh Kalappa]

Hi Segher and ERic

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).

Thank you
~Umesh

On Thu, May 16, 2019 at 9:00 AM Umesh Kalappa <umesh.kalappa0@gmail.com> wrote:
>
> >>Can't you get the loader fixed, instead?
> Yes we are thinking the same ,question what should be loader semantics here (update the prologue code to update r12 to Global Entry Point or Update R2 with toc base (that don't relay on the R12). )
>
> ~Umesh
> On Thu, May 16, 2019, 05:22 Segher Boessenkool <segher@kernel.crashing.org> wrote:
>>
>> On Wed, May 15, 2019 at 08:31:27PM +0200, Eric Botcazou wrote:
>> > > Thank you Eric for the suggestion and say that we support in the  loader
>> > > part ,can you please point on elfv2 reference that says implementation for
>> > > this specific case.
>> >
>> > I don't think there is a reference to this specific case in the ABI, only the
>> > general stuff about local and global entry points.
>>
>> Yes, it is just a normal jump to a local function.
>>
>> > We have had this patch in
>> > our tree for some time and it works well, so let me submit it for inclusion in
>> > the official tree.
>>
>> Can't you get the loader fixed, instead?
>>
>>
>> Segher

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

[Segher Boessenkool]

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.

Please open a PR so we can investigate?


Segher

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

[Umesh Kalappa]

Hi Segher,

Please refer the https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90513 .

Thank you
~Umesh

On Fri, May 17, 2019 at 4:22 AM Segher Boessenkool
<segher@kernel.crashing.org> 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.
>
> Please open a PR so we can investigate?
>
>
> Segher

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

[Kewen.Lin]

Hi,

on 2019/5/16 脡脧脦莽7:37, Segher Boessenkool wrote:
> Hi Umesh,
> 
> Please spell out "global entry point", almost everything and everyone does.
> 
> On Wed, May 15, 2019 at 08:57:29PM +0530, Umesh Kalappa wrote:
> 
>>         .set    .LTHUNK0,_ZN12Intermediate1vEv
> 
>> _ZThn8_N12Intermediate1vEv:
>> .LCF2:
>> 0:      addis 2,12,.TOC.-.LCF2@ha
>>         addi 2,2,.TOC.-.LCF2@l
>>         .localentry     _ZThn8_N12Intermediate1vEv,.-_ZThn8_N12Intermediate1vEv
>>         b .LTHUNK0
> 
>> _ZN12Intermediate1vEv:
>> .LCF1:
>> 0:      addis 2,12,.TOC.-.LCF1@ha
>>         addi 2,2,.TOC.-.LCF1@l
> 
>> like above the control  from "_ZThn8_N12Intermediate1vEv" (support
>> function for this pointer update)  is transferred
>> "_ZN12Intermediate1vEv" by b  inst (where its not updating the r12)
>> and in the beginning  of   "_ZN12Intermediate1vEv" we are loading the
>> toc base from r12 (which is incorrect ) ,we are investigating the
>> issue and one way to fix the issue is that make THUNK to update the
>> r12 ,the cal like bctrl  or  load the r12 with the function address in
>> the _ZN12Intermediate1vEv prologue code .
> 
> The thunk should point to the local entry point instead, I guess?
> 

I do think so.  The call is locally, linker should know it's local and 
fix it up with local entry instead.  We don't need to keep r12 always
hold the entry of being called function.

> Please open a PR, with compilable testcase, and other relevant info (if
> you need some specific -mcpu= for example, or other flags, do mention
> that!)  See https://gcc.gnu.org/bugs.html for more info.  Thanks!
> 
> 
> Segher
> 

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

[Eric Botcazou]

> I do think so.  The call is locally, linker should know it's local and
> fix it up with local entry instead.  We don't need to keep r12 always
> hold the entry of being called function.

Yes, but on VxWorks in kernel mode you first do partial linking and then the 
loader resolves the remaining relocations.  None of them plays the usual dance 
with the local and global entry points implied by the ELFv2 ABI.

-- 
Eric Botcazou

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

[Kewen.Lin]

Hi Eric,

Thanks for the information!  Sorry to know dual entry isn't supported
well on VxWorks.

Thanks,
Kewen

on 2019/5/17 脧脗脦莽3:24, Eric Botcazou wrote:
>> I do think so.  The call is locally, linker should know it's local and
>> fix it up with local entry instead.  We don't need to keep r12 always
>> hold the entry of being called function.
> 
> Yes, but on VxWorks in kernel mode you first do partial linking and then the 
> loader resolves the remaining relocations.  None of them plays the usual dance 
> with the local and global entry points implied by the ELFv2 ABI.
> 

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

[Alan Modra]

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.

-- 
Alan Modra
Australia Development Lab, IBM

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

[Segher Boessenkool]

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:

        .globl _ZN12Intermediate1vEv
...
        .set    .LTHUNK0,_ZN12Intermediate1vEv
...
        .globl _ZThn8_N12Intermediate1vEv
        .type   _ZThn8_N12Intermediate1vEv, @function
_ZThn8_N12Intermediate1vEv:
        .cfi_startproc
.LCF2:
0:      addis 2,12,.TOC.-.LCF2@ha
        addi 2,2,.TOC.-.LCF2@l
        .localentry _ZThn8_N12Intermediate1vEv,.-_ZThn8_N12Intermediate1vEv
        addi 3,3,-8
        b .LTHUNK0
        .cfi_endproc
.LFE27:
        .size   _ZThn8_N12Intermediate1vEv,.-_ZThn8_N12Intermediate1vEv


Segher

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

[Alan Modra]

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

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

[Segher Boessenkool]

On Mon, May 20, 2019 at 05:48:52PM +0930, Alan Modra wrote:
> 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:
> > > > 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.

I guess I read that wrong then -- I read it as "when a linker changes
some jump so that it goes to a global entry point".

But it means it needs to make a stub for every global entry point that
is used?


Segher

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

[Alan Modra]

On Mon, May 20, 2019 at 03:39:50AM -0500, Segher Boessenkool wrote:
> But it means it needs to make a stub for every global entry point that
> is used?

Mostly.  Calls via function pointer don't (*), nor do you need stubs
when generating inline PLT calls.  I'll note that use of the global
entry point for direct calls is closely associated with needing a PLT
entry, and the stubs we're talking about here are similar to the code
other architectures put in their .plt section.

*) The exception is when a non-PIC executable initialises a function
pointer in read-only memory to a function defined outside the
executable.  This case requires a special stub in the executable to
serve as the address of the function.

-- 
Alan Modra
Australia Development Lab, IBM