Re: Tuple and changes for m68k with -malign-int
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
Reply to: