This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]