Implementing a special case of cross-module sibling calls in assembly on 64-bit PowerPC

[Alan Modra]

On Wed, Mar 21, 2018 at 11:08:10AM -0400, Zack Weinberg wrote:
> On Wed, Mar 21, 2018 at 10:21 AM, Zack Weinberg <zackw@panix.com> wrote:
> >
> > Having read the ABI spec, I understand that in the general case this
> > is unsafe, because it could lead to the branch-ee returning to a
> > function that wasn't prepared to restore its own TOC pointer.
> > However, in this specific case, we know by construction that it _is_
> > safe, because these stub symbols are never called from within
> > libpthread, so whoever did call the version of 'vfork' (or whatever)
> > defined in libpthread must have done so with a proper cross-module
> > call sequence itself, and will restore its TOC when ultimately
> > returned to.
> 
> I think I figured it out for myself.  What I wanted to do _isn't_ safe
> because the "linkage stub" will clobber the caller's saved TOC.  What
> I should do instead is open-code a modified linkage stub:
> 
> .__pstub_vfork:
>     ld     r12, __libc_vfork@got@plt(r2)
>     ld     r0, 0(r12)
>     ld     r2, 8(r12)
>     mtctr  r0
>     bctr
> 
> This differs from the canonical stub in _not_ saving r2, since we
> don't have a stack frame of our own to save it into.  Check my logic,
> please?

Yes, this approach is correct.  For those reading this on the binutils
list, I replied with example code that ought to work even with quite
old tools at https://sourceware.org/ml/libc-alpha/2018-03/msg00540.html

-- 
Alan Modra
Australia Development Lab, IBM