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
