From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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=HEADER_FROM_DIFFERENT_DOMAINS, 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: from second.openwall.net (second.openwall.net [193.110.157.125]) by inbox.vuxu.org (Postfix) with SMTP id 8EDC222D58 for ; Mon, 29 Jan 2024 17:47:01 +0100 (CET) Received: (qmail 16234 invoked by uid 550); 29 Jan 2024 16:44:37 -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 16196 invoked from network); 29 Jan 2024 16:44:37 -0000 Date: Mon, 29 Jan 2024 11:47:02 -0500 From: Rich Felker To: musl@lists.openwall.com Cc: Hongliang Wang Message-ID: <20240129164702.GR4163@brightrain.aerifal.cx> References: <20240125174353.GW22081@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20240125174353.GW22081@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] loongarch64 merge On Thu, Jan 25, 2024 at 12:43:54PM -0500, Rich Felker wrote: > I'm going through where everything was left on this topic and > preparing a patch for merge. This message/thread is to document what > I'm actually doing vs the various submitted versions of the patch > since v5/v6 where the major review took place. > > > Subsequent changes I'm reverting: > > - De-optimization of __get_tp. No motivation for removing the > potentially in-place $tp was provided, and we generally use the > arch's tp in-place unless there's a compiler bug to be worked > around. See powerpc{,64} for an example where it's used, or1k where > we have a probably-obsolete workaround for ancient clang being > broken. > > - unsigned -> unsigned int, etc. > > - Gratuitous whitespace changes in headers that obscure the fact that > a header is a complete duplicate that could eventually be shared > between archs (e.g. bits/float.h, bits/posix.h) or just obscure > what differs from other archs when running diff. > > > Fixes from previous review that were overlooked: > > - Removing SA_RESTORER -- its presence defined as 0 produces wrong > sigaction ABI. > > > Additions: > > - Adding the reloc.h/configure case for single-only float. > > - The new member names for mcontext_t are all in reserved namespace, > so there's no reason to have a separate namespace-clean version of > mcontext_t, and I'm removing the latter. > > - Public member uc_flags with no __, macro for compat with any > existing software using the __-prefixed name. > > > Still TODO: > > I don't think I ever reviewed the apparent rewrite of sigsetjmp and > possibly some other asm that changed between v5 and v8. I'm about to > start looking at that and will follow up. OK, sigsetjmp appears to have been non-working in v5 (it failed to save the argument anywhere, so attempted it use it after it was clobbered in the code path after calling setjmp). v8 fixes this and seems like it should work, but I don't understand the offsets used. The loongarch64 __jmp_buf has 23 slots, but only appears to use 21 of them, with sigsetjmp storing its extra data in the last 2 unused slots. The contract here is supposed to be that the entirety of __jmp_buf belongs to setjmp/longjmp, with sigsetjmp using the extra space in the full jmp_buf/sigjmp_buf type with signal mask and lots of extra space. Were these slots added just for sigsetjmp? If so, that was an ABI mistake, but I don't think it warrants a late change; it's probably better to just leave them there as extensibility. Either way, I think sigsetjmp should be modified not to rely on storage in space that setjmp is entitled to be able to modify, i.e. it should be using offsets 184 and 184+16, not 168 and 176. Rich