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 29773 invoked from network); 19 May 2022 21:29:30 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 19 May 2022 21:29:30 -0000 Received: (qmail 17834 invoked by uid 550); 19 May 2022 21:29:28 -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 17795 invoked from network); 19 May 2022 21:29:27 -0000 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=message-id:date:mime-version:user-agent:subject:content-language:to :cc:references:from:in-reply-to:content-transfer-encoding; bh=CrPYYEe9HKAOla36iZH/6yyD1V0qQqXY/FQz1f6hz5o=; b=D5k5pJ3g/uyRA9GfLz1qjZEuNm9DMLdPEV+gG1AphgwjqVv51tiVvyMq+fdrKY7Hhx hnyr1x0VNK2RuebOVKm4mdCOctRkuFBSPAKISbDv+0kzVqiAafWBnKWDt9SBRLPEgTCR TBvfW8t2vBR/+NMUQ63qdYY9dDtUoMkzdblP02APBmFZvslQzdtLo9bIgBf+DrqnhqP2 Q1LFtXdOgKarDgObjHcJVtbfIj7ShICD0T3Q4Yocq0ErGYymw+UP/fFWnzqa0YdyLOMU CMfhcRxp6Ef6WdurQtVrQGJnMTdUaaPnpQ8lMhexM5kEDmJLcwqiS0DzsuQwutf+wCoi gGiQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:message-id:date:mime-version:user-agent:subject :content-language:to:cc:references:from:in-reply-to :content-transfer-encoding; bh=CrPYYEe9HKAOla36iZH/6yyD1V0qQqXY/FQz1f6hz5o=; b=dUkwV6h+U5YLwoll6vxpO9f1lLIfk8s1QjZfb65ysUKw7727M1djdUlJ/ssX/b67XS 4yhd8+XPJ1W52HXaL8WG3DQPEi2hbixToonKoyjHQvPpMAYtXTaDbCKH/5RmtSXfGvSp 91lEpuYqbFteddIn0hRLPW0fx4Xayu7cTPZXprlx6ul7sYSSNhp6AvvKPyrg1b5giNCw s9AsHPMASMfeuMCSBr3NgWovjpd0EdZ6NsS6fFgq5sNthmDFJpmv4D0dNm04rexXtJd0 BOpMqMirhr1Q1IiWLnL1T3PniTpOGwUgWu7OSHRnlFy4470zn/ec6glDV0e8Xs3yBxNo zRvA== X-Gm-Message-State: AOAM531mW8wMVz/zvYZ/aYcNJdioZT/5elAeJiCShNyY//oFFeaxM79D IUFxLQqddzEclIQNQzjw8HI= X-Google-Smtp-Source: ABdhPJzTdGf/nRsI7q8xq2IKVvHX8lLUtgUDx6TGZTSe7yqOgvHJy3LquxXDPQ3IXX0wHo++PUVxmQ== X-Received: by 2002:a17:903:181:b0:161:d2d2:751d with SMTP id z1-20020a170903018100b00161d2d2751dmr6486944plg.91.1652995755331; Thu, 19 May 2022 14:29:15 -0700 (PDT) Message-ID: <5bfd2fc7-c71e-c72b-d5f3-18c9ac7c3789@gmail.com> Date: Thu, 19 May 2022 14:29:13 -0700 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Content-Language: en-US To: Stafford Horne Cc: musl@lists.openwall.com, dalias@libc.org, thomas.petazzoni@bootlin.com, stefan.kristiansson@saunalahti.fi References: <20220517215826.1016573-1-f.fainelli@gmail.com> From: Florian Fainelli In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Subject: [musl] Re: [PATCH v2] Define user_regs, elf_greg_t and elf_fpregset_t for or1k On 5/18/2022 9:18 PM, Stafford Horne wrote: > 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]; OK, thanks! > > > 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. Yes, I think there must have been some confusion that procfs.h might be related to manipulating the /proc filesystem on Linux when it is not. I will submit a patch to buildroot backporting the pull request: https://github.com/opsengine/cpulimit/pull/110 Thanks! -- Florian