From: Christophe Leroy <christophe.leroy@c-s.fr>
To: Nicholas Piggin <npiggin@gmail.com>,
linuxppc-dev@lists.ozlabs.org, binutils@sourceware.org
Cc: libc-dev@lists.llvm.org, Rich Felker <dalias@libc.org>,
libc-alpha@sourceware.org,
Adhemerval Zanella <adhemerval.zanella@linaro.org>,
musl@lists.openwall.com, Thomas Gleixner <tglx@linutronix.de>,
Andy Lutomirski <luto@kernel.org>,
Vincenzo Frascino <vincenzo.frascino@arm.com>
Subject: [musl] Re: New powerpc vdso calling convention
Date: Sat, 25 Apr 2020 09:47:08 +0200 [thread overview]
Message-ID: <9371cac5-20bb-0552-2609-0d537f41fecd@c-s.fr> (raw)
In-Reply-To: <1587790194.w180xsw5be.astroid@bobo.none>
Le 25/04/2020 à 07:22, Nicholas Piggin a écrit :
> As noted in the 'scv' thread, powerpc's vdso calling convention does not
> match the C ELF ABI calling convention (or the proposed scv convention).
> I think we could implement a new ABI by basically duplicating function
> entry points with different names.
I think doing this is a real good idea.
I've been working at porting powerpc VDSO to the GENERIC C VDSO, and the
main pitfall has been that our vdso calling convention is not compatible
with C calling convention, so we have go through an ASM entry/exit.
See https://patchwork.ozlabs.org/project/linuxppc-dev/list/?series=171469
We should kill this error flag return through CR[SO] and get it the
"modern" way like other architectectures implementing the C VDSO: return
0 when successfull, return -err when failed.
>
> 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.
>
> 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/)
>
> Thanks,
> Nick
>
Christophe
next prev parent reply other threads:[~2020-04-25 10:49 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 ` Christophe Leroy [this message]
2020-04-25 10:56 ` [musl] " 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
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=9371cac5-20bb-0552-2609-0d537f41fecd@c-s.fr \
--to=christophe.leroy@c-s.fr \
--cc=adhemerval.zanella@linaro.org \
--cc=binutils@sourceware.org \
--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=npiggin@gmail.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).