From: Nicholas Piggin <npiggin@gmail.com>
To: Rich Felker <dalias@libc.org>
Cc: Adhemerval Zanella <adhemerval.zanella@linaro.org>,
binutils@sourceware.org,
Christophe Leroy <christophe.leroy@c-s.fr>,
libc-alpha@sourceware.org, libc-dev@lists.llvm.org,
linuxppc-dev@lists.ozlabs.org, Andy Lutomirski <luto@kernel.org>,
musl@lists.openwall.com, Thomas Gleixner <tglx@linutronix.de>,
Vincenzo Frascino <vincenzo.frascino@arm.com>
Subject: Re: [musl] Re: New powerpc vdso calling convention
Date: Sun, 26 Apr 2020 09:07:57 +1000 [thread overview]
Message-ID: <1587855503.8grsasuwof.astroid@bobo.none> (raw)
In-Reply-To: <20200425162204.GJ11469@brightrain.aerifal.cx>
Excerpts from Rich Felker's message of April 26, 2020 2:22 am:
> On Sat, Apr 25, 2020 at 08:56:54PM +1000, Nicholas Piggin wrote:
>> >> The ELF v2 ABI convention would suit it well, because the caller already
>> >> requires the function address for ctr, so having it in r12 will
>> >> eliminate the need for address calculation, which suits the vdso data
>> >> page access.
>> >>
>> >> Is there a need for ELF v1 specific calls as well, or could those just be
>> >> deprecated and remain on existing functions or required to use the ELF
>> >> v2 calls using asm wrappers?
>> >
>> > What's ELF v1 and ELF v2 ? Is ELF v1 what PPC32 uses ? If so, I'd say
>> > yes, it would be good to have it to avoid going through ASM in the middle..
>>
>> I'm not sure about PPC32. On PPC64, ELFv2 functions must be called with
>> their address in r12 if called at their global entry point. ELFv1 have a
>> function descriptor with call address and TOC in it, caller has to load
>> the TOC if it's global.
>>
>> The vdso doesn't have TOC, it has one global address (the vdso data
>> page) which it loads by calculating its own address.
>
> A function descriptor could be put in the VDSO data page, or as it's
> done now by glibc the vdso linkage code could create it. My leaning is
> to at least have a version of the code that's callable (with the right
> descriptor around it) by v1 binaries, but since musl does not use
> ELFv1 at all we really have no stake in this and I'm fine with
> whatever outcome users of v1 decide on.
I agree, I think it would be good to make it look as much like a normal
function as possible.
>> The kernel doesn't change the vdso based on whether it's called by a v1
>> or v2 userspace (it doesn't really know itself and would have to export
>> different functions). glibc has a hack to create something:
>
> I'm pretty sure it does know because signal invocation has to know
> whether the function pointer points to a descriptor or code. At least
> for FDPIC archs (similar to PPC64 ELFv1 function descriptors) it knows
> and has to know.
It knows on a per-executable basis (by looking at the ELF header). It
doesn't know per-system though so we can't patch the vdso accordingly.
But we could include both sets of entry points and map in the
appropriate one at exec time I think.
>> >> Is there a good reason for the system call fallback to go in the vdso
>> >> function rather than have the caller handle it?
>> >
>> > I've seen at least one while porting powerpc to the C VDSO: arguments
>> > toward VDSO functions are in volatile registers. If the caller has to
>> > call the fallback by itself, it has to save them before calling the
>> > VDSO, allthought in 99% of cases it won't use them again. With the
>> > fallback called by the VDSO itself, the arguments are still hot in
>> > volatile registers and ready for calling the fallback. That make it very
>> > easy to call them, see patch 5 in the series
>> > (https://patchwork.ozlabs.org/project/linuxppc-dev/patch/59bea35725ab4cefc67a678577da8b3ab7771af5.1587401492.git.christophe.leroy@c-s.fr/)
>
> This is actually a good reason not to spuriously fail and fallback. At
> present musl wouldn't take advantage of it because musl uses the
> fallback path for lazy initialization of the vdso function pointer and
> doesn't special-case the MIPS badness, but if it made a big difference
> we probably could shuffle things around to only do the fallback on
> archs that need it and avoid saving the input arg registers across the
> vdso call.
It's a point for it yes. I don't know if any libc or app would want to
instrument it or do special accounting or something for system calls.
Thanks,
Nick
next prev parent reply other threads:[~2020-04-25 23:11 UTC|newest]
Thread overview: 15+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-04-25 5:22 [musl] " Nicholas Piggin
2020-04-25 5:40 ` Rich Felker
2020-04-25 7:47 ` [musl] " Christophe Leroy
2020-04-25 10:56 ` Nicholas Piggin
2020-04-25 12:20 ` Christophe Leroy
2020-04-25 22:58 ` Nicholas Piggin
2020-04-25 23:11 ` Rich Felker
2020-04-26 3:41 ` Nicholas Piggin
2020-04-27 13:09 ` Adhemerval Zanella
2020-04-29 2:39 ` Nicholas Piggin
2020-04-29 12:15 ` Adhemerval Zanella
2020-05-05 21:56 ` Segher Boessenkool
2020-04-25 16:22 ` Rich Felker
2020-04-25 23:07 ` Nicholas Piggin [this message]
2020-04-30 2:51 ` Michael Ellerman
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=1587855503.8grsasuwof.astroid@bobo.none \
--to=npiggin@gmail.com \
--cc=adhemerval.zanella@linaro.org \
--cc=binutils@sourceware.org \
--cc=christophe.leroy@c-s.fr \
--cc=dalias@libc.org \
--cc=libc-alpha@sourceware.org \
--cc=libc-dev@lists.llvm.org \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=luto@kernel.org \
--cc=musl@lists.openwall.com \
--cc=tglx@linutronix.de \
--cc=vincenzo.frascino@arm.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.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/musl/
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 NNTP newsgroup(s).