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 42676240B5 for ; Fri, 26 Jan 2024 02:37:10 +0100 (CET) Received: (qmail 3643 invoked by uid 550); 26 Jan 2024 01:34:57 -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 3609 invoked from network); 26 Jan 2024 01:34:56 -0000 Date: Thu, 25 Jan 2024 20:37:13 -0500 From: Rich Felker To: Fangrui Song Cc: musl@lists.openwall.com Message-ID: <20240126013710.GM4163@brightrain.aerifal.cx> References: <20240125174353.GW22081@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] loongarch64 merge On Thu, Jan 25, 2024 at 05:18:21PM -0800, Fangrui Song wrote: > On Thu, Jan 25, 2024 at 9:43 AM 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. > > > > > > Attached are a "differences vs v8" patch and what my cumulative patch > > looks like right now. > > > > Rich > > There are a few new relocation types, including R_LARCH_ALIGN (102), > some ULEB128 ones, and some TLSDESC ones. > > https://github.com/loongson/la-abi-specs/blob/release/laelf.adoc I'd kinda wished the elf.h stuff had been done as a separate patch prepping for the port (since having new archs' elf constants in elf.h has value even without a musl port to the arch). If you (or anyone else) want to propose patches for this or any other new archs we're missing, I'd be happy to separate that out, but unless it's ready right away I don't want to hold up this port any longer on minor details. I mainly just want to make sure what gets merged (1) doesn't have broken ABI, (2) follows policy, and (3) is reasonably easy to analyze to see what actually differs between archs, and easy to follow any further change history made later. Getting back to this as I'd promised was really the last big thing holding up a release, which I know folks have been eagar for for a long time, and I'd like to move on with it asap and not let this get put off again. Rich