public inbox for libc-help@sourceware.org
 help / color / mirror / Atom feed
From: James Le Cuirot <chewi@aura-online.co.uk>
To: libc-help@sourceware.org
Cc: John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de>
Subject: Tuple and changes for m68k with -malign-int
Date: Sat, 26 Aug 2023 09:53:30 +0100	[thread overview]
Message-ID: <e9035006d50933fb02727fa373629cc821784f6c.camel@aura-online.co.uk> (raw)

Hello,

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. :)

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.

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.

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 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.

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.


--- 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?

Thanks for helping to keep m68k alive.

Regards,
Chewi

             reply	other threads:[~2023-08-26  8:53 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-26  8:53 James Le Cuirot [this message]
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
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=e9035006d50933fb02727fa373629cc821784f6c.camel@aura-online.co.uk \
    --to=chewi@aura-online.co.uk \
    --cc=glaubitz@physik.fu-berlin.de \
    --cc=libc-help@sourceware.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).