From: Zack Weinberg <zackw@panix.com>
To: Alan Modra <amodra@gmail.com>
Cc: GNU C Library <libc-alpha@sourceware.org>
Subject: Re: [RFC PATCH] Introduce pt-compat-stubs and use it to replace pt-vfork. (Architecture maintainer feedback wanted.)
Date: Fri, 23 Mar 2018 16:11:00 -0000 [thread overview]
Message-ID: <CAKCAbMhFyx+hYbvzbGmQ5t18xMDU_bHAyXQW-YFS-sWtW92PUg@mail.gmail.com> (raw)
In-Reply-To: <20180322234708.GS3812@bubble.grove.modra.org>
On Thu, Mar 22, 2018 at 7:47 PM, Alan Modra <amodra@gmail.com> wrote:
>
> 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..
Yeah, this is subtle enough that I think that was probably the right call...
...
> 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.
Lazy linking would be _better_, since these stubs exist only for
compatibility with old executables and shouldn't get called very
often, but I think we can live with eager linking. It's probably not
a measurable difference in the time it takes to load libpthread.so
anyway.
> For ELFv2, something like:
...
Thanks, I was trying to work these out myself (see the message I sent
to binutils@) and got stuck because the ABI spec uses
pseudo-relocation notation that the assembler doesn't actually accept.
It was also not clear to me that ELFv2 scrapped function descriptors;
you wouldn't happen to know where there's a list of *changes* from v1
to v2, would you?
> .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)
Is this third load (to r11) from the function descriptor required?
That's the static chain slot, which C doesn't use, I thought...
zw
next prev parent reply other threads:[~2018-03-23 16:11 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
2018-03-23 16:11 ` Zack Weinberg [this message]
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=CAKCAbMhFyx+hYbvzbGmQ5t18xMDU_bHAyXQW-YFS-sWtW92PUg@mail.gmail.com \
--to=zackw@panix.com \
--cc=amodra@gmail.com \
--cc=libc-alpha@sourceware.org \
/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).