Bug in example .glink resolver stub #85

On Wed, Apr 25, 2018 at 09:55:11PM +0000, Sean Fertile wrote:

In section 4.2.5.3. Procedure Linkage Table the example glink resolver stub has a bug where we use r0 as an input to a subi instruction. r0 as an input is treated as literal 0 rather then using the contents of r0.

What is there now:

Compute .plt section index from entry point address in r12

.plt section index is placed into r0 as argument to the resolver

sub r0,r12,r11
subi r0,r0,res_0-1b
srdi r0,r0,2

Yes, that's a bit silly.

We clobber r12 right after this sequence so we could update this to:
sub r12,r12,r11
subi r0,r12,res_0-1b
srdi r0,r0,2

Looks good to me.

For reference, what the linker actually generates for the resolver on
powerpc64le is:

__glink_PLTresolve:
mflr r0
bcl 20,4*cr7+so,10000960 <__glink_PLTresolve+0x8>
mflr r11
std r2,24(r1)
ld r2,-16(r11)
mtlr r0
subf r12,r11,r12
add r11,r2,r11
addi r0,r12,-48
ld r12,0(r11)
rldicl r0,r0,62,2
mtctr r12
ld r11,8(r11)
bctr

Which is the same as your recommended update to the ABI with
a) using r2 to load PLToffset
b) saving r2 for localentry:0 function calls
c) insn reordering

a) was done just because you can use r2..
b) is necessary because when the --plt-localentry linker optimization
is enabled, ld generates plt call stubs for localentry:0 functions
that don't save r2, and there's no toc restore insn. That works
for calls that go directly via the plt, but not when you need to go
via the resolver for lazy plt resolution. So the resolver stub
saves r2 and r2 is restored by ld.so.
c) was done in a probably vain attempt to do a little better insn
scheduling.

--
Alan Modra
Australia Development Lab, IBM

On Wed, Apr 25, 2018 at 09:55:11PM +0000, Sean Fertile wrote: > In section `4.2.5.3. Procedure Linkage Table` the example glink resolver stub has a bug where we use r0 as an input to a subi instruction. r0 as an input is treated as literal 0 rather then using the contents of r0. > > What is there now: > # Compute .plt section index from entry point address in r12 > # .plt section index is placed into r0 as argument to the resolver > sub r0,r12,r11 > subi r0,r0,res_0-1b > srdi r0,r0,2 Yes, that's a bit silly. > We clobber r12 right after this sequence so we could update this to: > sub r12,r12,r11 > subi r0,r12,res_0-1b > srdi r0,r0,2 Looks good to me. For reference, what the linker actually generates for the resolver on powerpc64le is: __glink_PLTresolve: mflr r0 bcl 20,4*cr7+so,10000960 <__glink_PLTresolve+0x8> mflr r11 std r2,24(r1) ld r2,-16(r11) mtlr r0 subf r12,r11,r12 add r11,r2,r11 addi r0,r12,-48 ld r12,0(r11) rldicl r0,r0,62,2 mtctr r12 ld r11,8(r11) bctr Which is the same as your recommended update to the ABI with a) using r2 to load PLToffset b) saving r2 for localentry:0 function calls c) insn reordering a) was done just because you can use r2.. b) is necessary because when the --plt-localentry linker optimization is enabled, ld generates plt call stubs for localentry:0 functions that don't save r2, and there's no toc restore insn. That works for calls that go directly via the plt, but not when you need to go via the resolver for lazy plt resolution. So the resolver stub saves r2 and r2 is restored by ld.so. c) was done in a probably vain attempt to do a little better insn scheduling. -- Alan Modra Australia Development Lab, IBM

Labels Milestones

Bug in example .glink resolver stub #85

Compute .plt section index from entry point address in r12

.plt section index is placed into r0 as argument to the resolver