Re: [RFC PATCH] Introduce pt-compat-stubs and use it to replace pt-vfork. (Architecture maintainer feedback wanted.)

[Alan Modra <amodra at gmail dot com>]

On Tue, Mar 20, 2018 at 09:05:51PM -0400, Zack Weinberg wrote:
> I believe I have managed to
> turn the trick for all currently-supported targets *except* powerpc64,
> where I cannot find a way around a linker sanity check.  The object
> file contains
> 
> 0000000000000000 <.__pstub_vfork>:
>    0:	48 00 00 00 	b       0 <.__pstub_vfork>
> 			0: R_PPC64_REL24	__libc_vfork
>    4:	60 00 00 00 	nop
> 
> and the linker throws this error:
> 
> nptl/libpthread_pic.a(pt-compat-stubs.os): In function `__pstub_vfork':
> .../pt-compat-stubs.S:56:(.text+0x0): call to `__libc_vfork@@GLIBC_PRIVATE'
>   lacks nop, can't restore toc; recompile with -fPIC
> 
> You can see that there *is* a nop after the call.

Yes, the error message isn't the best in this case.  At one stage GNU
ld did allow code like you're writing.  ie. a useless nop to be
replaced with a toc restore insn that won't ever be executed.  It
was a way for an assembly programmer to say they knew what they were
doing, please don't complain "can't restore toc".  I took that feature
out after getting reports of crashes due to bad toc pointer values..

>  GNU ld lumps
> several different circumstances into this error message, one of which
> is just that R_PPC64_REL24 to a symbol outside the current module has
> been applied to a plain branch (as opposed to branch-and-link)
> instruction.  *Normally* this would be unsafe, but in this specific
> case, I believe it would work fine: __pstub_vfork is never called from
> within libpthread, so __libc_vfork will ultimately return to a
> TOC-restoration shim within __pstub_vfork's own caller.

Yes, if you can guarantee no local calls to __pstub_vfork then the
trick should work OK.

>  There's
> some code in bfd/elf64-ppc.c that makes it sound like there might be a
> way to bypass the sanity check,
> 
>               if (stub_entry->stub_type == ppc_stub_plt_call
>                   && !htab->opd_abi
>                   && htab->params->plt_localentry0 != 0
>                   && is_elfv2_localentry0 (&h->elf))
>                 {
>                   /* The function doesn't use or change r2.  */
>                   can_plt_call = TRUE;
>                 }
> 
> but I can't figure out how to make that condition be true.  Any help
> would be appreciated.

No, that code won't apply.  You'd need to link with --plt-localentry
and __libc_vfork isn't localentry:0 anyway.

   937: 00000000000e5f64    52 FUNC    GLOBAL DEFAULT [<localentry>: 8]    10 __libc_vfork@@GLIBC_PRIVATE

Do you need lazy linking of the __libc_vfork PLT entry?  If not, you
could just implement the stub as an indirect call to __libc_vfork.

For ELFv2, something like:

 .text
 .global __pstub_vfork
 .type __pstub_vfork,@function
__pstub_vfork:
0:
 addis 12,12,1f-0b@ha
 addi 12,12,1f-0b@l
 ld 12,0(12)
 mtctr 12
 bctr
 .size __pstub_vfork,.-0b

 .data
1:
 .quad __libc_vfork

ELFv1 code would look like:

 .section .opd,"aw",@progbits
 .global __pstub_vfork
 .type __pstub_vfork,@function
__pstub_vfork:
 .quad 0f,.TOC.,0

 .text
0:
 addis 11,2,1f-0b@ha
 addi 11,11,1f-0b@l
 ld 11,0(11)
 ld 12,0(11)
 mtctr 12
 ld 2,8(11)
 ld 11,16(11)
 bctr
 .size __pstub_vfork,.-0b

 .data
1:
 .quad __libc_vfork

Note the addi and ld look like they ought to be combined into one
insn, but we lack a REL16_LO_DS reloc to make that kosher.

-- 
Alan Modra
Australia Development Lab, IBM