Date: Sun, 26 Apr 2020 09:07:57 +1000 From: Nicholas Piggin <npiggin@...il.com> To: Rich Felker <dalias@...c.org> Cc: Adhemerval Zanella <adhemerval.zanella@...aro.org>, binutils@...rceware.org, Christophe Leroy <christophe.leroy@....fr>, libc-alpha@...rceware.org, libc-dev@...ts.llvm.org, linuxppc-dev@...ts.ozlabs.org, Andy Lutomirski <luto@...nel.org>, musl@...ts.openwall.com, Thomas Gleixner <tglx@...utronix.de>, Vincenzo Frascino <vincenzo.frascino@....com> Subject: Re: Re: New powerpc vdso calling convention 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://firstname.lastname@example.org/) > > 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
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.