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_ADSP_CUSTOM_MED, DKIM_INVALID,DKIM_SIGNED,FREEMAIL_FROM,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 15238 invoked from network); 25 Apr 2020 05:26:05 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with UTF8ESMTPZ; 25 Apr 2020 05:26:05 -0000 Received: (qmail 1866 invoked by uid 550); 25 Apr 2020 05:26:02 -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 1836 invoked from network); 25 Apr 2020 05:26:01 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:mime-version:message-id :content-transfer-encoding; bh=2HOADhTkAeksIfTBCZQLnFFLjEGrFQSgemgFeHgUpTQ=; b=ndMz/kmBh0Ub/KAdOAf+xOuLKJ9R4AuOt08zym3J7hyPMFLCrhvjF3BnoD9T6++2+a RpUC6wTv6p9uhBfsVc6WWsplAIQokLQlbrCsmDT0oo+iE4HL+NorP9rTzOile2m1tnvM I94s4tO15J3hjs/eAQRr5gcKKP4u53KDMQBH2484RPkobM3mU6sFR4b+lw2xa14d8wTY b1MvJ92TTFMgChp+O974pPWaRWJJWZjkOXAL2k1Zs4gD+YJby8C+QOdruAtvTPve4hjR ebePR8Fkta5Ze763UosgH211HYrq8X5TGW26oSXnX0TuiZ7xOr2w7RZ2QIAyMxiMhL/W FJLQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:subject:to:cc:mime-version:message-id :content-transfer-encoding; bh=2HOADhTkAeksIfTBCZQLnFFLjEGrFQSgemgFeHgUpTQ=; b=QYh4M6FpGXhBQZpw+jf1NtTYviGZZmDJwTDxUtTGy9IQqS1R8VRJmBpBLatdSLntpI sJAhnZ1bo9bgmX/0PAQStosvAav1BVstn6zYsGDBZeVOC1yICf2h76+NjNCKADrx9ndE Leb7+cmpFsrbUYeT9/EJvtERuViqGGvLYmT1VbyjXQA2oQyA6kN5P4ewWkgrufrQxKTS HSgurleQVkcujtOMqYkcBETks7d8djoD3CytBzffH++VmMATnnK1szWaJ/VsCr1y/OaN 4eADc1saFcQAAestQ+iX4FhhNGs6X5dWiLVjrLT49qKd+RPYnT2BC4lpjOzdMdbTJzJk YBAw== X-Gm-Message-State: AGi0PuZxQkCHvWvCqnbLcj9tw4nxDFUwfYh/WuqyHaO0KZNb58LSEoDT 0oxouT6K5Co8emqGbBwacOE= X-Google-Smtp-Source: APiQypIYBLaRpub6XaHOpLMaYg70Dxmn7zJlSNgCHVkcOFtI2rc8iaGSvVraXD4RSzeizrLJf5oqIw== X-Received: by 2002:a17:90b:8c4:: with SMTP id ds4mr4964810pjb.133.1587792349141; Fri, 24 Apr 2020 22:25:49 -0700 (PDT) Date: Sat, 25 Apr 2020 15:22:27 +1000 From: Nicholas Piggin To: linuxppc-dev@lists.ozlabs.org, binutils@sourceware.org Cc: libc-alpha@sourceware.org, libc-dev@lists.llvm.org, musl@lists.openwall.com, Adhemerval Zanella , Rich Felker MIME-Version: 1.0 Message-Id: <1587790194.w180xsw5be.astroid@bobo.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [musl] New powerpc vdso calling convention As noted in the 'scv' thread, powerpc's vdso calling convention does not=20 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. 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=20 eliminate the need for address calculation, which suits the vdso data=20 page access. Is there a need for ELF v1 specific calls as well, or could those just be=20 deprecated and remain on existing functions or required to use the ELF=20 v2 calls using asm wrappers? Is there a good reason for the system call fallback to go in the vdso=20 function rather than have the caller handle it? Thanks, Nick