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=-1.0 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2 autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 22054 invoked from network); 4 Apr 2023 17:06:53 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 4 Apr 2023 17:06:53 -0000 Received: (qmail 14012 invoked by uid 550); 4 Apr 2023 17:06:48 -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 13977 invoked from network); 4 Apr 2023 17:06:47 -0000 Date: Tue, 4 Apr 2023 19:06:35 +0200 From: Szabolcs Nagy To: =?utf-8?B?546L5rSq5Lqu?= Cc: Rich Felker , musl@lists.openwall.com Message-ID: <20230404170635.GJ3630668@port70.net> Mail-Followup-To: =?utf-8?B?546L5rSq5Lqu?= , Rich Felker , musl@lists.openwall.com References: <20230129170407.GL4163@brightrain.aerifal.cx> <7c77f6d5-7f42-f3a9-af81-99a251780d19@loongson.cn> <20230216231336.GW4163@brightrain.aerifal.cx> <2775a5e6-1fc0-e542-47ea-e90170053654@loongson.cn> <00d245b2-c0b5-9978-7f7b-9d5aa5df6137@loongson.cn> <20230403133523.GG3630668@port70.net> <20230403144248.GE4163@brightrain.aerifal.cx> <20230403154435.GH3630668@port70.net> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable In-Reply-To: Subject: Re: [musl] add loongarch64 port v6. * =E7=8E=8B=E6=B4=AA=E4=BA=AE [2023-04-04 17:46= :36 +0800]: > =E5=9C=A8 2023/4/3 =E4=B8=8B=E5=8D=8811:44, Szabolcs Nagy =E5=86=99=E9=81= =93: > > i was asking because of this glibc patch: > > https://sourceware.org/pipermail/libc-alpha/2023-April/146897.html > >=20 > > i dont understand that change (loongarch is in glibc since 2.36 release= ). >=20 > Based on the v6 patch,I Modified the member names of struct sigcontext to > maintain > consistency with kernel and glibc. As shown in (1) if _XOPEN_SOURCE && !_GNU_SOURCE && !_BSD_SOURCE mcontext_t fields need not be accessible and must be in the impl reserved namespace (no glibc or linux api compat requirement, only posix namespace req). (2) otherwise musl mcontext_t fields must match glibc. (ucontext and mcontext_t must use the same api across libcs). i think it does not matter if the fields are different from the linux uapi sigcontext fields. glibc used to include linux asm/sigcontext.h to define mcontext_t so the fields were the same, but that polluted the namespace and got fixed a while ago: https://sourceware.org/bugzilla/show_bug.cgi?id=3D21457 since then mcontext_t is not the same as struct sigcontext, but even before that they should not have been used interchangably in c apis (the c abi must match though). so i would not change the glibc code to match linux. and update the musl patch to match current glibc api. the only wart i see is that all targets currently have an uc_flags field in ucontext, loongarch has an __uc_flags, but i think that's fine if there is no portable use of this field. you may want to look into that, but it can be fixed with a #define uc_flags __uc_flags if needed. the glibc loongarch maintainers can break their api (and c++ abi) if they wish to make it consistent with linux uapi, but i don't think that's very useful. i'd wait for the glibc patch to be resolved and fix musl patches accordingly. the v6 patches currently violate both (1) and (2) requirements.