mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: Fangrui Song <i@maskray.me>
Cc: musl@lists.openwall.com
Subject: Re: [musl] loongarch64 merge
Date: Thu, 25 Jan 2024 20:37:13 -0500	[thread overview]
Message-ID: <20240126013710.GM4163@brightrain.aerifal.cx> (raw)
In-Reply-To: <DS7PR12MB5765687BC1E9EBC9C8C991F0CB792@DS7PR12MB5765.namprd12.prod.outlook.com>

On Thu, Jan 25, 2024 at 05:18:21PM -0800, Fangrui Song wrote:
> On Thu, Jan 25, 2024 at 9:43 AM Rich Felker <dalias@libc.org> 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

  reply	other threads:[~2024-01-26  1:37 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-01-25 17:43 Rich Felker
2024-01-26  1:18 ` Fangrui Song
2024-01-26  1:37   ` Rich Felker [this message]
2024-01-29 16:47 ` Rich Felker
2024-01-30  7:35   ` Hongliang Wang
2024-02-23  3:26     ` Hongliang Wang
2024-02-23 15:36       ` Rich Felker
2024-02-26  1:50 Hongliang Wang
     [not found] ` <Pine.BSM.4.64L.2402260157280.14519@herc.mirbsd.org>
2024-02-26  9:45   ` Hongliang Wang
2024-02-26 15:41     ` Thorsten Glaser
2024-02-27  1:07       ` Hongliang Wang

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20240126013710.GM4163@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=i@maskray.me \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).