[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sat, 25 Apr 2020 20:56:54 +1000
From: Nicholas Piggin <npiggin@...il.com>
To: binutils@...rceware.org, Christophe Leroy <christophe.leroy@....fr>,
linuxppc-dev@...ts.ozlabs.org
Cc: Adhemerval Zanella <adhemerval.zanella@...aro.org>, Rich Felker
<dalias@...c.org>, libc-alpha@...rceware.org, libc-dev@...ts.llvm.org,
Andy Lutomirski <luto@...nel.org>, musl@...ts.openwall.com, Thomas Gleixner
<tglx@...utronix.de>, Vincenzo Frascino <vincenzo.frascino@....com>
Subject: Re: New powerpc vdso calling convention
Excerpts from Christophe Leroy's message of April 25, 2020 5:47 pm:
>
>
> 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.
Agreed.
>> 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.
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:
# define VDSO_IFUNC_RET(value) \
({ \
static Elf64_FuncDesc vdso_opd = { .fd_toc = ~0x0 }; \
vdso_opd.fd_func = (Elf64_Addr)value; \
&vdso_opd; \
})
If we could make something which links more like any other dso with
ELFv1, that would be good. Otherwise I think v2 is preferable so it
doesn't have to calculate its own address.
>> 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/)
I see. Well the kernel can probably patch in sc or scv depending on
which is supported, so we could keep the automatic fallback.
Thanks,
Nick
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
