From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: (qmail 27208 invoked from network); 25 Apr 2020 16:22:21 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with UTF8ESMTPZ; 25 Apr 2020 16:22:21 -0000 Received: (qmail 15433 invoked by uid 550); 25 Apr 2020 16:22:17 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 15415 invoked from network); 25 Apr 2020 16:22:17 -0000 Date: Sat, 25 Apr 2020 12:22:04 -0400 From: Rich Felker To: Nicholas Piggin Cc: binutils@sourceware.org, Christophe Leroy , linuxppc-dev@lists.ozlabs.org, Adhemerval Zanella , libc-alpha@sourceware.org, libc-dev@lists.llvm.org, Andy Lutomirski , musl@lists.openwall.com, Thomas Gleixner , Vincenzo Frascino Message-ID: <20200425162204.GJ11469@brightrain.aerifal.cx> References: <1587790194.w180xsw5be.astroid@bobo.none> <9371cac5-20bb-0552-2609-0d537f41fecd@c-s.fr> <1587810370.tg8ym9yjpc.astroid@bobo.none> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1587810370.tg8ym9yjpc.astroid@bobo.none> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Re: New powerpc vdso calling convention 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. > 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. > >> 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. Rich