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.1 required=5.0 tests=DKIM_INVALID,DKIM_SIGNED, 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 23410 invoked from network); 25 Apr 2020 15:50:11 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with UTF8ESMTPZ; 25 Apr 2020 15:50:11 -0000 Received: (qmail 1313 invoked by uid 550); 25 Apr 2020 15:50:09 -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 7807 invoked from network); 25 Apr 2020 12:21:06 -0000 Authentication-Results: localhost; dkim=pass reason="1024-bit key; insecure key" header.d=c-s.fr header.i=@c-s.fr header.b=eThJ3L6f; dkim-adsp=pass; dkim-atps=neutral X-Virus-Scanned: Debian amavisd-new at c-s.fr DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=c-s.fr; s=mail; t=1587817253; bh=xduG0f9KUHs/JAaDeRgGH/5x4mQMN6KPZKL81TT97d8=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=eThJ3L6fw0DV8f8IdsJRpCR/Bbc2147rkCKxNgMeDk+ozxnljyvVSRcEs0kcZxRiH CaX/6R36ILVLhYnQOYIzfk4ti0WgXOf0jt3Fi+zNPO1DSj2JLmcYG2gzKNrRKSNWnf gb5UE7dvUn7chsVll04EVgUh9I7byqrSTqm5xSpg= X-Virus-Scanned: amavisd-new at c-s.fr To: Nicholas Piggin , binutils@sourceware.org, linuxppc-dev@lists.ozlabs.org Cc: Adhemerval Zanella , Rich Felker , libc-alpha@sourceware.org, libc-dev@lists.llvm.org, Andy Lutomirski , musl@lists.openwall.com, Thomas Gleixner , Vincenzo Frascino References: <1587790194.w180xsw5be.astroid@bobo.none> <9371cac5-20bb-0552-2609-0d537f41fecd@c-s.fr> <1587810370.tg8ym9yjpc.astroid@bobo.none> From: Christophe Leroy Message-ID: <976551e8-229e-54c1-8fb2-c5df94b979c3@c-s.fr> Date: Sat, 25 Apr 2020 14:20:45 +0200 User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <1587810370.tg8ym9yjpc.astroid@bobo.none> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit Subject: [musl] Re: New powerpc vdso calling convention Le 25/04/2020 à 12:56, Nicholas Piggin a écrit : > 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. I see the following in glibc. So looks like PPC32 is like PPC64 elfv1. By the way, they are talking about something not completely finished in the kernel. Can we finish it ? #if (defined(__PPC64__) || defined(__powerpc64__)) && _CALL_ELF != 2 /* The correct solution is for _dl_vdso_vsym to return the address of the OPD for the kernel VDSO function. That address would then be stored in the __vdso_* variables and returned as the result of the IFUNC resolver function. Yet, the kernel does not contain any OPD entries for the VDSO functions (incomplete implementation). However, PLT relocations for IFUNCs still expect the address of an OPD to be returned from the IFUNC resolver function (since PLT entries on PPC64 are just copies of OPDs). The solution for now is to create an artificial static OPD for each VDSO function returned by a resolver function. The TOC value is set to a non-zero value to avoid triggering lazy symbol resolution via .glink0/.plt0 for a zero TOC (requires thread-safe PLT sequences) when the dynamic linker isn't prepared for it e.g. RTLD_NOW. None of the kernel VDSO routines use the TOC or AUX values so any non-zero value will work. Note that function pointer comparisons will not use this artificial static OPD since those are resolved via ADDR64 relocations and will point at the non-IFUNC default OPD for the symbol. Lastly, because the IFUNC relocations are processed immediately at startup the resolver functions and this code need not be thread-safe, but if the caller writes to a PLT slot it must do so in a thread-safe manner with all the required barriers. */ #define VDSO_IFUNC_RET(value) \ ({ \ static Elf64_FuncDesc vdso_opd = { .fd_toc = ~0x0 }; \ vdso_opd.fd_func = (Elf64_Addr)value; \ &vdso_opd; \ }) #else #define VDSO_IFUNC_RET(value) ((void *) (value)) #endif Christophe