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 19567 invoked from network); 25 Apr 2020 10:49:29 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with UTF8ESMTPZ; 25 Apr 2020 10:49:29 -0000 Received: (qmail 31774 invoked by uid 550); 25 Apr 2020 10:49:25 -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 29882 invoked from network); 25 Apr 2020 07:47:24 -0000 Authentication-Results: localhost; dkim=pass reason="1024-bit key; insecure key" header.d=c-s.fr header.i=@c-s.fr header.b=THusQfcD; 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=1587800831; bh=PqeD2DO3sbweUF9JsA7ETZbDEPz8S5WdPQqjMK+1FlY=; h=Subject:To:Cc:References:From:Date:In-Reply-To:From; b=THusQfcDtHDAzJtFQp0biVe0+gqPX/L+K0WHt03JUZC26XXb60XIltzaDPK76G0Cv SZ6/nEhdpg8frAH1xO3egSiK2aVzHfMQRO9Oiw/HozBFpgsqb0sburLMBVpgVo+7JB XKox5i1T8BIabeHLSeXdBfSvq44aQv2vy4X/UJRI= X-Virus-Scanned: amavisd-new at c-s.fr To: Nicholas Piggin , linuxppc-dev@lists.ozlabs.org, binutils@sourceware.org Cc: libc-dev@lists.llvm.org, Rich Felker , libc-alpha@sourceware.org, Adhemerval Zanella , musl@lists.openwall.com, Thomas Gleixner , Andy Lutomirski , Vincenzo Frascino References: <1587790194.w180xsw5be.astroid@bobo.none> From: Christophe Leroy Message-ID: <9371cac5-20bb-0552-2609-0d537f41fecd@c-s.fr> Date: Sat, 25 Apr 2020 09:47:08 +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: <1587790194.w180xsw5be.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 à 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