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, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 26044 invoked from network); 19 May 2022 04:18:54 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 19 May 2022 04:18:54 -0000 Received: (qmail 7579 invoked by uid 550); 19 May 2022 04:18:51 -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 7536 invoked from network); 19 May 2022 04:18:50 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=dtGFROU0DrijqmMMAVd7TQ6lfcOGhk2o6EBvxhZeL+k=; b=Jv2zy22UggTwXxEpjwDj60md+xr9th/4yH5Q23InEMSjvnoEtzzk3bdVR5FlkxyN+e xKdgFw1naB9CepLVL/2zmPYOpZXCckNNg9nmZ7zBbu+12l1RdBUqz0OgcZcaL5WR+ayd GfERc/XjqDUz1nogyWEFMF76/5Thm/873OTNByy/B39jpfWCbCQ7Dh1X7d0hLJnpbYm1 +0G6BtzTf/Iq3TNMbjDFWqnggHVyzm+vl7Na9e+6+5TzmgJtyVFK1CK1dpqKcqlhlQod 2Je7UHtGMPjVN6UlzKGQDKyeDEUPSxZsaXVTJsF/7ogCe9n+xN1rh9EVYJF395tdWKiy 0IcA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=dtGFROU0DrijqmMMAVd7TQ6lfcOGhk2o6EBvxhZeL+k=; b=SXgsebM5aq6BpcuZJj4palznb2UKSMcsZ8B5eFAHWwbqCBBRyS1ET/+S06FoNd16hg DzBTnh61cejmzMESNPVx3+wDzi7k0v7zXDZtfHJnRFfITGadSLmT3F0bOXpUi9gZqmY8 2NGk9XTcTx9ZNcQJuLt08bqTlTKXj3kfi4YeEoJ7fvoU/of2FoDwfUNcpen6w/DJG7pt /M+NNTVZH5I1OKiU8mTPHgpKYO9qJEc/7L47Rcp7eH9JSAcaq8OcpbJNUdvvet4DCnRt NBgPyUc+F3l8YcRxHss8uZe5y/T5aEax+jriZCvEPTMEFkljisWbBFyKwANGTN9Fqyzi e9/A== X-Gm-Message-State: AOAM53195FN+At1vZOChkO2cTHSyEx2kl6+rufzw20sDV4amF4aow+hX ECMXF+zHNfBHYL10GElb6tY= X-Google-Smtp-Source: ABdhPJxAqu8w7RbRkeE6vHwGbvXUPS1jG/pYUi+bPy5B+SnlkfyLcSwSNlf4gCTKIEtrOmx7Uyn3/Q== X-Received: by 2002:a05:6a00:134f:b0:50e:10e0:ef82 with SMTP id k15-20020a056a00134f00b0050e10e0ef82mr3042302pfu.45.1652933918177; Wed, 18 May 2022 21:18:38 -0700 (PDT) Date: Thu, 19 May 2022 13:18:35 +0900 From: Stafford Horne To: Florian Fainelli Cc: musl@lists.openwall.com, dalias@libc.org, thomas.petazzoni@bootlin.com, stefan.kristiansson@saunalahti.fi Message-ID: References: <20220517215826.1016573-1-f.fainelli@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220517215826.1016573-1-f.fainelli@gmail.com> Subject: [musl] Re: [PATCH v2] Define user_regs, elf_greg_t and elf_fpregset_t for or1k On Tue, May 17, 2022 at 02:58:26PM -0700, Florian Fainelli wrote: > The OpenRISC architecture is currently missing a definition of its > user_regs structure, elf_greg_t and elf_fpregset_t as well as ELF_NGREG, > add those. > --- > Changes in v2: > > - Follow Stafford's recommendations based upon glibc > > arch/or1k/bits/user.h | 10 ++++++++++ > 1 file changed, 10 insertions(+) > > diff --git a/arch/or1k/bits/user.h b/arch/or1k/bits/user.h > index e69de29bb2d1..227f022e2fec 100644 > --- a/arch/or1k/bits/user.h > +++ b/arch/or1k/bits/user.h > @@ -0,0 +1,10 @@ > +struct user_regs { > + unsigned long gpr[32]; > + unsigned long pc; > + unsigned long sr; > +}; > + > +#define ELF_NGREG 32 > +typedef unsigned long elf_greg_t, elf_gregset_t[ELF_NGREG]; > + I think ELF_NGREG should be 34 here. On glibc we defined this like this, but I am beginning to doubt it is correct: (sys/ucontext.h) #define __NGREG 32 (bits/procfs.h) #define ELF_NGREG __NGREG typedef elf_greg_t elf_gregset_t[34]; In linux and some other architectures they define ELF_NGREG as below (so that would mean 34 is right): #define ELF_NGREG (sizeof (struct user_regs_struct) / sizeof (elf_greg_t)) In linux we define this, so yours matches. (arch/openrisc/include/uapi/asm/ptrace.h) truct user_regs_struct { /* GPR R0-R31... */ unsigned long gpr[32]; unsigned long pc; unsigned long sr; }; > +typedef elf_greg_t elf_fpregset_t[ELF_NGREG]; This should be: typedef elf_greg_t elf_fpregset_t[32]; However, I have tested all of glibc with the definition as above with ELF_NGREG 32 and elf_gregset_t[34]. But, I think I will like to change that and test again. So in the end I think we should use this. #define ELF_NGREG (sizeof (struct user_regs) / sizeof (elf_greg_t)) typedef elf_greg_t elf_gregset_t[ELF_NGREG]; typedef elf_greg_t elf_fpregset_t[32]; Side Point I am not sure why cpulimit needs elf_gregset_t anyway. I see it includes procfs.h, I removed that include and it seems to compile ok. -Stafford