From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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.4 Received: (qmail 21009 invoked from network); 20 May 2021 05:12:24 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 20 May 2021 05:12:24 -0000 Received: (qmail 7189 invoked by uid 550); 20 May 2021 05:12:22 -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 6132 invoked from network); 20 May 2021 05:12:21 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:subject:to:cc:references:in-reply-to:mime-version :message-id:content-transfer-encoding; bh=06KbBafvZa4BBa7qjQ5t4Am1mOBvJg6DGbGd+FkhvIo=; b=SjwGtmcDH9Dh2Wa3o93Ep2jhjm/8TTVH3xfAVFiHA6HLIlQGDOiUOYPoR9swNmwwWw g6Du+E+WtmyC+XMX2QeNWcok8I0Bg+de1cR2bGbKemu5W8oMaa01xnJbtDg1MXQWnZ3v 2aQzsPgctouIxwwx4Dz90xjR/6o+keoZUfdpSP35DZm2/5t1wcfHxHJ31xXPZ3bBwvef 1fcmkU7ze/3AdnYCLrFQ+whOzHJaugQ5uJjFmc6t+57ikS88hbUFd1I3LlUZpOPYIDEb 7zJ9OobpoMMi+DZtlZ1Ba5AHdAike7i8YwmeaDk1Y1Vd8KxARwPJbeMHcLSItvDyqRBX ptjw== 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:references:in-reply-to :mime-version:message-id:content-transfer-encoding; bh=06KbBafvZa4BBa7qjQ5t4Am1mOBvJg6DGbGd+FkhvIo=; b=KlYZ47Oa9LJVFSvGTMv28+XOBBrSX1ypM3/wMm1HKxg4FzZVyeD4xuBcyBOKem1l+x ywWxMahvhLJxVwnWzKNm74C3DB2ow+1fPljabNT2brrkY28GNPfgMKo0vwaaggVWKGzn /VDFP6ddrNQkRiKkvGGZhDC5ijZffgPMPIXvzYufZvTmO3DvB5Fxtlb3MS2J2QIbj8Vx FhWPO+7GahFRMWnQXtYFMXxYaj5SHxZqWMnb4KaiK++uw8Z7Ogr3UVNBUVuAGysz2bAv fgEKGhYT9kKIizyRjY1bjUrxlw29gqRNC8XpfE76+3auKAJXtThJsCyelLg3eOTJ6ttt M7Dg== X-Gm-Message-State: AOAM531zyJ/ulznR772dYsrHlHeQHrO5i9T+NvlnVYT/y4RlMfyogOlx CWVIspOE+ZnvWD+bkoYFcfY= X-Google-Smtp-Source: ABdhPJwolGPVF5FlLMl8HVNpTzFe2D2mSODdHbw80a4ZQL7Y9ldFq6/WktutOjh5f6y7+7kfokjoaA== X-Received: by 2002:a17:902:db0f:b029:f3:e5f4:87f1 with SMTP id m15-20020a170902db0fb02900f3e5f487f1mr3699593plx.26.1621487529004; Wed, 19 May 2021 22:12:09 -0700 (PDT) Date: Thu, 20 May 2021 15:12:03 +1000 From: Nicholas Piggin To: "Dmitry V. Levin" Cc: Joakim Tjernlund , libc-alpha@sourceware.org, libc-dev@lists.llvm.org, linux-api@vger.kernel.org, linuxppc-dev@lists.ozlabs.org, Michael Ellerman , Matheus Castanho , musl@lists.openwall.com References: <20210519132656.GA17204@altlinux.org> <1621464056.o9t21cquw8.astroid@bobo.none> <20210519232726.GA24134@altlinux.org> <1621478238.xha1ow4ujh.astroid@bobo.none> <20210520030611.GB27081@altlinux.org> In-Reply-To: <20210520030611.GB27081@altlinux.org> MIME-Version: 1.0 Message-Id: <1621487263.hkgxyf500s.astroid@bobo.none> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Subject: [musl] Re: Linux powerpc new system call instruction and ABI Excerpts from Dmitry V. Levin's message of May 20, 2021 1:06 pm: > On Thu, May 20, 2021 at 12:40:36PM +1000, Nicholas Piggin wrote: > [...] >> > Looks like struct pt_regs.trap already contains the information that c= ould >> > be used to tell 'sc' from 'scv': if (pt_regs.trap & ~0xf) =3D=3D 0x300= 0, then >> > it's scv. Is my reading of arch/powerpc/include/asm/ptrace.h correct? >>=20 >> Hmm, I think it is. Certainly in the kernel regs struct it is, I had in=20 >> my mind that we put it to 0xc00 when populating the user struct for >> compatibility, but it seems not. So I guess this would work. >=20 > OK, can we state that (pt_regs.trap & ~0xf) =3D=3D 0x3000 is a part of th= e scv > ABI, so it's not going to change and could be relied upon by userspace? > Could this be documented in Documentation/powerpc/syscall64-abi.rst, > please? Yeah I think we can do that. The kernel doesn't care what is put in the userspace pt_regs.trap too much so if this is your preferred approach then I will document it in the ABI. Thanks, Nick