public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
From: James Le Cuirot <chewi@aura-online.co.uk>
To: Finn Thain <fthain@linux-m68k.org>,
	John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Cc: libc-help@sourceware.org,
	debian-68k <debian-68k@lists.debian.org>,
	 linux-m68k <linux-m68k@vger.kernel.org>
Subject: Re: Tuple and changes for m68k with -malign-int
Date: Sun, 27 Aug 2023 10:20:16 +0100	[thread overview]
Message-ID: <751c83150533b701d66ac24c8fe81863cf5eab98.camel@aura-online.co.uk> (raw)
In-Reply-To: <80a52487-3105-ed5b-a1eb-ec1a0689ef21@linux-m68k.org>

On Sun, 2023-08-27 at 10:46 +1000, Finn Thain wrote:
> On Sat, 26 Aug 2023, John Paul Adrian Glaubitz wrote:
> 
> > On Sat, 2023-08-26 at 09:53 +0100, James Le Cuirot wrote:
> 
> > ...
> 
> > 
> > Not only mold but also most notably the following projects:
> > 
> > - LLVM
> > - Firebird Database
> > - OpenJDK
> > - Various Qt packages
> > 
> 
> And potentially more in the future, which may be anticipated on the basis 
> that "those users don't need a stable ABI any more, so let's just ignore 
> the portability issues in our code and leave the problem to the distros 
> and toolchain developers".
> 
> That is the precedent you would set.
> 
> Moreover, why is it that only a few developers have a problem with making 
> explicit their decisions regarding alignment of shorts? What actual pain 
> does it cause them to accept a patch to make their struct layouts plain?

Some projects do accept patches. Yann Collet was even kind enough to fix this
in zstd themselves. On the other hand, we have had to fight to stop Python
from dropping m68k support entirely. The real problem is the effort required
to produce these patches. I haven't been able to wrap my head around this so
far, but I would still like to learn. I could see myself eventually fixing
mold, but LLVM feels like a very tall order.

> > > We need to break the ABI anyway with time_t going 64-bit, so it makes 
> > > sense to do these two things at the same time.
> > 
> > Fully agreed.
> > 
> 
> If the kernel breaks the ABI, that's a bug, not an excuse. Either you're 
> okay with proliferation of incompatible binaries and tools or there are 
> some criteria (yet to be identified AFAIK) which permit this bug.

If you're referring to time_t, the kernel is not breaking the ABI. New
syscalls were added to 32-bit architectures for 64-bit time_t. The
incompatibility is within userland, such as in the curl vs GnuTLS example I
mentioned.

> It's not difficult to foresee fragmentation because it follows from the 
> manpower shortage. There will always be sufficient manpower to produce a 
> break that pleases a few. There may never be enough manpower to produce a 
> stable ABI that pleases everyone for the foreseeable future.
> 

Since this is about userland, are you suggesting that all userland ABIs should
simultaneously support both 32-bit and 64-bit time_t? That would never happen,
especially when 32-bit time_t will naturally become useless.

> > I think -gnu32 sounds very reasonable.
> 
> You do? I think 32 is misleading in the absence of 16-bit or 64-bit 
> variants, and -gnu is misleading if other tooling like LLVM already 
> supports malign-int. Moreover, it's impossible to align to a bit count in 
> general. Not that you'd want to -- it's actually the natural alignment of 
> shorts that is at issue, AIUI.

I picked -gnu because this is a variation on what we have already and I've
never heard of glibc using anything other than -gnu*. You still use -gnu when
building with Clang, so I'm not sure what Clang supporting -malign-int has to
do with it. Of course, glibc is not the only libc, but the others are not
compatible anyway and have their own tuples. They will presumably follow suit
though, as they have done in the past, e.g. -gnueabihf -> -musleabihf.

> So, for naming purposes, the proposal might be described as either the ABI 
> du jour (leading to -abi23 for 2023) or the new ABI for ever (leading to 
> -abin as in -gnuabin32 on MIPS).
> 
> If it's the former, perhaps you should not push it upstream. If it's the 
> latter, perhaps this redesign should seek to address real shortcomings 
> with the existing ABI, including problems which (for all I know) may have 
> entirely prevented some people from using it thus far. That is, it should 
> consider silicon beyond 680x0.

I'm not sure what you mean here. I don't think anyone has been prevented from
using the existing ABI when it is the only m68k ABI on Linux. We *are*
considering other architectures with the time_t issue. I haven't heard anyone
shouting about any other common issues. They should really be shouting about
time_t, as it is somewhat pressing, but surprisingly little has been said
about it.

I do know that m68k Linux has been significantly slower since the transition
from linuxthreads to NPTL due to the lack of a spare register, but I gather
nothing can be done about that.

  reply	other threads:[~2023-08-27  9:20 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-26  8:53 James Le Cuirot
2023-08-26 10:51 ` John Paul Adrian Glaubitz
2023-08-26 19:24   ` Richard
2023-08-26 20:43     ` James Le Cuirot
2023-08-28  6:54       ` Geert Uytterhoeven
2023-08-28 10:57     ` John Paul Adrian Glaubitz
2023-08-28 12:11       ` Richard
2023-08-28 12:22         ` Geert Uytterhoeven
2023-08-28 12:46         ` John Paul Adrian Glaubitz
2023-08-27  0:46   ` Finn Thain
2023-08-27  9:20     ` James Le Cuirot [this message]
2023-08-27 11:27       ` Richard
2023-08-28  7:00       ` Geert Uytterhoeven
2023-08-28 11:26         ` Richard
2023-08-28 11:40           ` Geert Uytterhoeven
2023-08-28 20:16           ` Richard
2023-08-29  6:52             ` Geert Uytterhoeven
2023-08-28  6:56     ` Geert Uytterhoeven
2023-08-28 11:13       ` John Paul Adrian Glaubitz
2023-08-29  1:12         ` Finn Thain
2023-08-28 11:10     ` John Paul Adrian Glaubitz
2023-08-28 12:44       ` Adhemerval Zanella Netto
2023-08-28 12:50         ` John Paul Adrian Glaubitz
2023-08-28 13:17           ` Andreas Schwab
2023-08-29 10:51             ` John Paul Adrian Glaubitz
2023-08-29 15:27               ` Geert Uytterhoeven
2023-08-28 13:29           ` James Le Cuirot
2023-08-29 10:54             ` John Paul Adrian Glaubitz
2023-08-29 21:53               ` Karoly Balogh
2023-08-30  1:33                 ` Jeffrey Walton
2023-08-29  1:14       ` Finn Thain
2023-08-29  8:52         ` Eero Tamminen
2023-08-28  5:15 ` Florian Weimer

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=751c83150533b701d66ac24c8fe81863cf5eab98.camel@aura-online.co.uk \
    --to=chewi@aura-online.co.uk \
    --cc=debian-68k@lists.debian.org \
    --cc=fthain@linux-m68k.org \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=libc-help@sourceware.org \
    --cc=linux-m68k@vger.kernel.org \
    /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.
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 read-only IMAP folder(s) and NNTP newsgroup(s).