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: Zack Weinberg <zackw at panix dot com>
- To: binutils at sourceware dot org
- Date: Wed, 21 Mar 2018 11:08:10 -0400
- 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>
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?
zw