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:
- LLVM
- Firebird Database
- OpenJDK
- Various Qt packages
It's a regular occurrence that a package doesn't build on m68k due to it's unusual
default alignment. Thus, in order to keep the port alive in the future, I think
switching to 32-bit alignment by default is inevitable.
It goes against the traditional ABIs, but practically no m68k Linux binaries
are published outside of distributions, so this not a concern. 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.
We in Gentoo fully support this idea. We had hoped that Debian would take the
initiative, but we're not aware of any movement yet, and we're keen to make
this transition, so I'm here to get the ball rolling.
We haven't had a larger discussion yet and I didn't want to impose any changes
before we have agreed on how to move forward. Thanks a lot for finally starting
the discussion.
We think this warrants a new tuple, and we'd like to ensure that everyone gets
behind the same one. It is currently m68k-*-gnu. Perhaps it could be
m68k-*-gnu32 or m68k-*-gnu32a? I considered gnu32i (for int), but the flag
actually affects floats and doubles too. I don't really care what it is
though, so feel free to suggest something totally different.
I think -gnu32 sounds very reasonable. I'm actually also wondering what is being
used for other ports that are going to be rebuilt with 64-bit time_t. Maybe we
could use that naming scheme. I guess using "gnu32" for any 32-bit port with
64-bit time_t might not be the obvious choice.
So, while I like the gnu32 suffix, I would suggest we do some research first to find
out what the commonly used triplet change will be used for 32-bit ports switching
to 64-bit time_t.
Once that is agreed, I'm happy to put together the patch to automatically
enable the flag for this tuple in GCC. The part I do need help with is
necessary changes to glibc, if any. Assembly is not my area at all, so what I
came up with here was a total guess.
Thanks for already looking into the implementation details!
--- a/sysdeps/m68k/crti.S 2022-07-29 23:03:09.000000000 +0100
+++ b/sysdeps/m68k/crti.S 2022-11-30 21:41:52.710135230 +0000
@@ -56,7 +56,7 @@
#endif
.section .init,"ax",@progbits
- .align 2
+ .p2align 2
.globl _init
.hidden _init
.type _init, @function
@@ -74,7 +74,7 @@
#endif
.section .fini,"ax",@progbits
- .align 2
+ .p2align 2
.globl _fini
.hidden _fini
.type _fini, @function
I did try this out, and it largely seemed to work, although processes
occasionally hung. Perhaps this was unrelated.
It was a while back now and I can't remember if I also built the Linux kernel
with -malign-int. Does it need to match? Presumably it would at least give the
same kind of performance benefit?
I cannot comment on this at the moment, so let's wait for the more experienced
m68k kernel and toolchain folks to chime in.
Thanks for helping to keep m68k alive.
Thank you, too, and thanks for getting this rolling!
Adrian
--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913
