This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Implementing a special case of cross-module sibling calls in assembly on 64-bit PowerPC
- From: Alan Modra <amodra at gmail dot com>
- To: Zack Weinberg <zackw at panix dot com>
- Cc: binutils at sourceware dot org
- Date: Sat, 24 Mar 2018 10:42:49 +1030
- Subject: Re: Implementing a special case of cross-module sibling calls in assembly on 64-bit PowerPC
- References: <CAKCAbMg3NDKfMX5JS+DgRLo18mk3czC-L4Q=rwN9AiV+V_5QpA@mail.gmail.com> <CAKCAbMg6BHJAOwXhSff0d0JtnaAFS2s7QCfrY-QzqjBqVXKXow@mail.gmail.com>
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