On Sat, 2023-08-26 at 19:24 +0000, Richard wrote:
On August 26, 2023 10:51:39 AM UTC, John Paul Adrian Glaubitz <glaubitz@xxxxxxxxxxxxxxxxxxx> wrote:
Hi James!
On Sat, 2023-08-26 at 09:53 +0100, James Le Cuirot wrote:
I wasn't sure whether to send this to libc-alpha or here. This feels more like
a request for help, so I decided to play it safe. :)
I am CC'ing Debian's m68k mailing list and the Linux m68k kernel mailing list
to make sure we're getting enough exposure.
The Debian m68k maintainers proposed building their packages with -malign-int
last year, aligning to 32-bit instead of 16-bit, which improves compatibility
with some projects and should give better performance on 68020+, at the cost
of slightly increased memory usage. The mold linker is at least one project
that has been shown to work after making this change where it previously
didn't.
Not only mold but also most notably the following projects:
a linker that is broken by a slightly unusual alignment isn't exactly a prime example.. if any project I would expect linkers and binary tools to pay attention to portability.
Not the best example, I grant you, but it was the only one where I'd
personally witnessed it making a difference so far.
It's a regular occurrence that a package doesn't build on m68k due to it's unusual
default alignment.
Unfortunately. Some time ago m68k was not the only one with this problem?
Possibly, but I wouldn't know. I suspect it may be the only one still in use
with Linux. Gentoo supports most of the architectures to some degree, and I'm
not aware of any those having this issue.
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.
What exactly will be broken? Afaics kernel ABIs have been since long pretty carefully designed to avoid this problems and noone of the mentioned examples should touch them anyway.
Thus.. is there any need to change the kernel ABI?
I mentioned the kernel, but I'm not sure whether that's actually affected.
This is more about userland compatibility in the same way that arm-*-gnu,
arm-*-gnueabi, and arm-*gnueabihf are incompatible with each other. I did try
mixing the latter two once. This was swiftly met with a segfault.
Of course, a tuple doesn't stop users from mixing these binaries, but it is a
good way to ensure that GCC enables the flag when appropriate. This is too
important to rely on CFLAGS.
As for time_t, I hadn't realised a different tuple was being proposed for
that, but a fellow Gentoo dev confirms. The breakage here is less severe but
still significant. I witnessed it first-hand on 32-bit ARM when GnuTLS started
using 64-bit time_t while curl was still expecting 32-bit, which lead to HTTPS
requests failing because the certificate start/end dates were completely
wrong. At that point, we realised this is something that needs to be applied
system-wide.
I believe we're still waiting on consensus for that too. gnu64time anyone?
It's 2023, how about gnu🕛64? ;)
