From: Alan Modra <amodra@gmail.com>
To: Zack Weinberg <zackw@panix.com>
Cc: libc-alpha@sourceware.org
Subject: Re: [RFC PATCH] Introduce pt-compat-stubs and use it to replace pt-vfork. (Architecture maintainer feedback wanted.)
Date: Thu, 22 Mar 2018 23:47:00 -0000 [thread overview]
Message-ID: <20180322234708.GS3812@bubble.grove.modra.org> (raw)
In-Reply-To: <20180321010551.9611-1-zackw@panix.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
next prev parent reply other threads:[~2018-03-22 23:47 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-03-21 1:05 Zack Weinberg
2018-03-21 8:53 ` Andreas Schwab
2018-03-21 13:25 ` Zack Weinberg
2018-03-21 13:59 ` Andreas Schwab
2018-03-21 14:01 ` Zack Weinberg
2018-03-21 14:27 ` Andreas Schwab
2018-03-22 23:47 ` Alan Modra [this message]
2018-03-23 16:11 ` Zack Weinberg
2018-03-23 19:32 ` Zack Weinberg
2018-03-23 23:46 ` Alan Modra
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180322234708.GS3812@bubble.grove.modra.org \
--to=amodra@gmail.com \
--cc=libc-alpha@sourceware.org \
--cc=zackw@panix.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).