Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

Hi,

I'm currently testing enabling 4 bytes alignment and first started looking into
what NetBSD does (gcc/config/m68k/linux.h in the GCC source). Surprisingly, this
is set to 64 and not 32 bits for the largest possible alignment.

The explanation is as follows:

/* No data type wants to be aligned rounder than this.                                                                                                                     
   For m68k/SVR4, some types (doubles for example) are aligned on 8 byte                                                                                                   
   boundaries */

#undef BIGGEST_ALIGNMENT
#define BIGGEST_ALIGNMENT 64

BIGGEST_ALIGNMENT is what's being toggled with the -malign-int option
in gcc/config/m68k/m68k.h:

/* No data type wants to be aligned rounder than this.                                                                                                                     
   Most published ABIs say that ints should be aligned on 16-bit                                                                                                           
   boundaries, but CPUs with 32-bit busses get better performance                                                                                                          
   aligned on 32-bit boundaries.  */
#define BIGGEST_ALIGNMENT (TARGET_ALIGN_INT ? 32 : 16)

In order to test GCC on Linux/m68k with 32-bit alignment, I just copied
the definitions from netbsd-elf.h into linux.h above which eventually
failed with:

free(): invalid pointer
during GIMPLE pass: slp
../../../../../src/libstdc++-v3/src/c++17/floating_from_chars.cc: In function 'std::from_chars_result std::from_chars(const char*, const char*, double&, chars_format)':
../../../../../src/libstdc++-v3/src/c++17/floating_from_chars.cc:1243:1: internal compiler error: Aborted

Now I'm wondering whether why some types on NetBSD such as double have 8 bytes
alignment on a 32-bit system. Does anyone know the reasoning for that?

And does libstdc++ have an additional codepath on NetBSD to deal with the
largest possible alignment to be 8 bytes so that the error above does not
occur?

Or could it just be a result of the ABI mismatch because glibc needs to be
patched as well?

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Jeffrey Walton]

On Mon, May 26, 2025 at 11:05 AM John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
>
> Hi,
>
> I'm currently testing enabling 4 bytes alignment and first started looking into
> what NetBSD does (gcc/config/m68k/linux.h in the GCC source). Surprisingly, this
> is set to 64 and not 32 bits for the largest possible alignment.
>
> The explanation is as follows:
>
> /* No data type wants to be aligned rounder than this.
>    For m68k/SVR4, some types (doubles for example) are aligned on 8 byte
>    boundaries */
>
> #undef BIGGEST_ALIGNMENT
> #define BIGGEST_ALIGNMENT 64
>
> BIGGEST_ALIGNMENT is what's being toggled with the -malign-int option
> in gcc/config/m68k/m68k.h:
>
> /* No data type wants to be aligned rounder than this.
>    Most published ABIs say that ints should be aligned on 16-bit
>    boundaries, but CPUs with 32-bit busses get better performance
>    aligned on 32-bit boundaries.  */
> #define BIGGEST_ALIGNMENT (TARGET_ALIGN_INT ? 32 : 16)
>
> In order to test GCC on Linux/m68k with 32-bit alignment, I just copied
> the definitions from netbsd-elf.h into linux.h above which eventually
> failed with:
>
> free(): invalid pointer
> during GIMPLE pass: slp
> ../../../../../src/libstdc++-v3/src/c++17/floating_from_chars.cc: In function 'std::from_chars_result std::from_chars(const char*, const char*, double&, chars_format)':
> ../../../../../src/libstdc++-v3/src/c++17/floating_from_chars.cc:1243:1: internal compiler error: Aborted
>
> Now I'm wondering whether why some types on NetBSD such as double have 8 bytes
> alignment on a 32-bit system. Does anyone know the reasoning for that?
>
> And does libstdc++ have an additional codepath on NetBSD to deal with the
> largest possible alignment to be 8 bytes so that the error above does not
> occur?
>
> Or could it just be a result of the ABI mismatch because glibc needs to be
> patched as well?

I don't know about the 64 byte alignment on NetBSD. Maybe it was
copied/pasted/modified from amd64? amd64 has a BIGGEST_ALIGNMENT of 64
due to AVX512. Prior to that, I believe amd64 had a BIGGEST_ALIGNMENT
of 32 due to AVX. (These were due to the aligned loads, like
_mm256_load_epi32 (32-byte requirement) or _mm512_load_epi32 (64-byte
requirement)).

For PowerPC with Altivec, I believe BIGGEST_ALIGNMENT should be 16.

I don't know if __ALTIVEC__ plays a part in BIGGEST_ALIGNMENT. That
is, should BIGGEST_ALIGNMENT be 4 (for int) or 8 (for doubles) unless
__ALTIVEC__ is defined; and if __ALTIVEC__ is defined, then
BIGGEST_ALIGNMENT should be 16.

Jeff

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

Hi Jeff,

On Mon, 2025-05-26 at 14:16 -0400, Jeffrey Walton wrote:
> I don't know about the 64 byte alignment on NetBSD. Maybe it was
> copied/pasted/modified from amd64? amd64 has a BIGGEST_ALIGNMENT of 64
> due to AVX512. Prior to that, I believe amd64 had a BIGGEST_ALIGNMENT
> of 32 due to AVX. (These were due to the aligned loads, like
> _mm256_load_epi32 (32-byte requirement) or _mm512_load_epi32 (64-byte
> requirement)).
> 
> For PowerPC with Altivec, I believe BIGGEST_ALIGNMENT should be 16.
> 
> I don't know if __ALTIVEC__ plays a part in BIGGEST_ALIGNMENT. That
> is, should BIGGEST_ALIGNMENT be 4 (for int) or 8 (for doubles) unless
> __ALTIVEC__ is defined; and if __ALTIVEC__ is defined, then
> BIGGEST_ALIGNMENT should be 16.

The alignment is specified in bits here, not bytes. Hence a BIGGEST_ALIGNMENT
of 64 means 8 bytes, not 64 bytes.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Jason Thorpe]

> On May 26, 2025, at 8:05 AM, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
> 
> Now I'm wondering whether why some types on NetBSD such as double have 8 bytes
> alignment on a 32-bit system. Does anyone know the reasoning for that?

Because that’s what is specified in the System V ABI for m68k.

     https://m680x0.github.io/ref/sysv-m68k-abi-part1.pdf

See Figure 3-1.  “double” and “long double” are explicitly 8-byte aligned.

-- thorpej

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Jeffrey Walton]

On Mon, May 26, 2025 at 2:23 PM John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
>
> On Mon, 2025-05-26 at 14:16 -0400, Jeffrey Walton wrote:
> > I don't know about the 64 byte alignment on NetBSD. Maybe it was
> > copied/pasted/modified from amd64? amd64 has a BIGGEST_ALIGNMENT of 64
> > due to AVX512. Prior to that, I believe amd64 had a BIGGEST_ALIGNMENT
> > of 32 due to AVX. (These were due to the aligned loads, like
> > _mm256_load_epi32 (32-byte requirement) or _mm512_load_epi32 (64-byte
> > requirement)).
> >
> > For PowerPC with Altivec, I believe BIGGEST_ALIGNMENT should be 16.
> >
> > I don't know if __ALTIVEC__ plays a part in BIGGEST_ALIGNMENT. That
> > is, should BIGGEST_ALIGNMENT be 4 (for int) or 8 (for doubles) unless
> > __ALTIVEC__ is defined; and if __ALTIVEC__ is defined, then
> > BIGGEST_ALIGNMENT should be 16.
>
> The alignment is specified in bits here, not bytes. Hence a BIGGEST_ALIGNMENT
> of 64 means 8 bytes, not 64 bytes.

Derp...

Maybe the 64-bits/8-bytes is coming from limitations in the linker.
See the discussion of __BIGGEST_ALIGNMENT__ at
<https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html>:

    On some systems, the linker is only able to arrange for variables to
    be aligned up to a certain maximum alignment. (For some linkers, the
    maximum supported alignment may be very very small.) If your linker
    is only able to align variables up to a maximum of 8-byte alignment,
    then specifying aligned(16) in an __attribute__ still only provides
    you with 8-byte alignment.

Jeff

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

Hi Jason,

On Mon, 2025-05-26 at 11:25 -0700, Jason Thorpe wrote:
> > On May 26, 2025, at 8:05 AM, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
> > 
> > Now I'm wondering whether why some types on NetBSD such as double have 8 bytes
> > alignment on a 32-bit system. Does anyone know the reasoning for that?
> 
> Because that’s what is specified in the System V ABI for m68k.
> 
>      https://m680x0.github.io/ref/sysv-m68k-abi-part1.pdf
> 
> See Figure 3-1.  “double” and “long double” are explicitly 8-byte aligned.

OK, that clarifies it, thank you!

FWIW, I have scanned the whole SysV ABI specification in case someone needs it:

https://people.debian.org/~glaubitz/m68k-sysv-abi.pdf

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Jean-Michel Hautbois]

Hi Adrian,

On 26/05/2025 17:05, John Paul Adrian Glaubitz wrote:
> Hi,
> 
> I'm currently testing enabling 4 bytes alignment and first started looking into
> what NetBSD does (gcc/config/m68k/linux.h in the GCC source). Surprisingly, this
> is set to 64 and not 32 bits for the largest possible alignment.
> 
> The explanation is as follows:
> 
> /* No data type wants to be aligned rounder than this.
>     For m68k/SVR4, some types (doubles for example) are aligned on 8 byte
>     boundaries */
> 
> #undef BIGGEST_ALIGNMENT
> #define BIGGEST_ALIGNMENT 64
> 
> BIGGEST_ALIGNMENT is what's being toggled with the -malign-int option
> in gcc/config/m68k/m68k.h:
> 
> /* No data type wants to be aligned rounder than this.
>     Most published ABIs say that ints should be aligned on 16-bit
>     boundaries, but CPUs with 32-bit busses get better performance
>     aligned on 32-bit boundaries.  */
> #define BIGGEST_ALIGNMENT (TARGET_ALIGN_INT ? 32 : 16)
> 
> In order to test GCC on Linux/m68k with 32-bit alignment, I just copied
> the definitions from netbsd-elf.h into linux.h above which eventually
> failed with:
> 
> free(): invalid pointer
> during GIMPLE pass: slp
> ../../../../../src/libstdc++-v3/src/c++17/floating_from_chars.cc: In function 'std::from_chars_result std::from_chars(const char*, const char*, double&, chars_format)':
> ../../../../../src/libstdc++-v3/src/c++17/floating_from_chars.cc:1243:1: internal compiler error: Aborted
> 
> Now I'm wondering whether why some types on NetBSD such as double have 8 bytes
> alignment on a 32-bit system. Does anyone know the reasoning for that?
> 
> And does libstdc++ have an additional codepath on NetBSD to deal with the
> largest possible alignment to be 8 bytes so that the error above does not
> occur?
> 
> Or could it just be a result of the ABI mismatch because glibc needs to be
> patched as well?

I tried to patch gcc-13 with this BIGGEST_ALIGNMENT set to 64. I am 
using buildroot+uclibc-ng on a Coldfire (mcf54418).

Everything build fine, except the kernel:

In function ‘siginfo_build_tests’,
     inlined from ‘restore_sigcontext’ at arch/m68k/kernel/signal.c:684:2,
     inlined from ‘do_sigreturn’ at arch/m68k/kernel/signal.c:775:9:
././include/linux/compiler_types.h:542:45: error: call to 
‘__compiletime_assert_351’ declared with attribute error: BUILD_BUG_ON 
failed: offsetof(siginfo_t, si_lower) != 0x12
   542 |         _compiletime_assert(condition, msg, 
__compiletime_assert_, __COUNTER__)
       |                                             ^
././include/linux/compiler_types.h:523:25: note: in definition of macro 
‘__compiletime_assert’
   523 |                         prefix ## suffix(); 
         \
       |                         ^~~~~~
././include/linux/compiler_types.h:542:9: note: in expansion of macro 
‘_compiletime_assert’
   542 |         _compiletime_assert(condition, msg, 
__compiletime_assert_, __COUNTER__)
       |         ^~~~~~~~~~~~~~~~~~~
./include/linux/build_bug.h:39:37: note: in expansion of macro 
‘compiletime_assert’
    39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), 
msg)
       |                                     ^~~~~~~~~~~~~~~~~~
./include/linux/build_bug.h:50:9: note: in expansion of macro 
‘BUILD_BUG_ON_MSG’
    50 |         BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " 
#condition)
       |         ^~~~~~~~~~~~~~~~
arch/m68k/kernel/signal.c:621:9: note: in expansion of macro ‘BUILD_BUG_ON’
   621 |         BUILD_BUG_ON(offsetof(siginfo_t, si_lower) != 0x12);
       |         ^~~~~~~~~~~~
make[5]: *** [scripts/Makefile.build:207: arch/m68k/kernel/signal.o] Error 1
make[4]: *** [scripts/Makefile.build:465: arch/m68k/kernel] Error 2
make[4]: *** Waiting for unfinished jobs....

This is a 6.14.
Any idea about this ?

Thanks,
JM

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

Hi Jean-Michel,

On Thu, 2025-06-05 at 08:24 +0200, Jean-Michel Hautbois wrote:
> I tried to patch gcc-13 with this BIGGEST_ALIGNMENT set to 64. I am 
> using buildroot+uclibc-ng on a Coldfire (mcf54418).

Thanks a lot for testing! Such contributions are highly appreciated.

> Everything build fine, except the kernel:
> 
> In function ‘siginfo_build_tests’,
>      inlined from ‘restore_sigcontext’ at arch/m68k/kernel/signal.c:684:2,
>      inlined from ‘do_sigreturn’ at arch/m68k/kernel/signal.c:775:9:
> ././include/linux/compiler_types.h:542:45: error: call to 
> ‘__compiletime_assert_351’ declared with attribute error: BUILD_BUG_ON 
> failed: offsetof(siginfo_t, si_lower) != 0x12
>    542 |         _compiletime_assert(condition, msg, 
> __compiletime_assert_, __COUNTER__)
>        |                                             ^
> ././include/linux/compiler_types.h:523:25: note: in definition of macro 
> ‘__compiletime_assert’
>    523 |                         prefix ## suffix(); 
>          \
>        |                         ^~~~~~
> ././include/linux/compiler_types.h:542:9: note: in expansion of macro 
> ‘_compiletime_assert’
>    542 |         _compiletime_assert(condition, msg, 
> __compiletime_assert_, __COUNTER__)
>        |         ^~~~~~~~~~~~~~~~~~~
> ./include/linux/build_bug.h:39:37: note: in expansion of macro 
> ‘compiletime_assert’
>     39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), 
> msg)
>        |                                     ^~~~~~~~~~~~~~~~~~
> ./include/linux/build_bug.h:50:9: note: in expansion of macro 
> ‘BUILD_BUG_ON_MSG’
>     50 |         BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: " 
> #condition)
>        |         ^~~~~~~~~~~~~~~~
> arch/m68k/kernel/signal.c:621:9: note: in expansion of macro ‘BUILD_BUG_ON’
>    621 |         BUILD_BUG_ON(offsetof(siginfo_t, si_lower) != 0x12);
>        |         ^~~~~~~~~~~~
> make[5]: *** [scripts/Makefile.build:207: arch/m68k/kernel/signal.o] Error 1
> make[4]: *** [scripts/Makefile.build:465: arch/m68k/kernel] Error 2
> make[4]: *** Waiting for unfinished jobs....
> 
> This is a 6.14.
> Any idea about this ?

It looks like this check needs to be patched:

	BUILD_BUG_ON(offsetof(siginfo_t, si_lower) != 0x12);

The source code in arch/m68k/kernel/signal.c contains a lot of hard-wired offsets
which will probably have to be adjusted.

You can try changing 0x12 to 0x14 and see if that fixes it.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Jean-Michel Hautbois]

Hi Adrian,

On 05/06/2025 08:39, John Paul Adrian Glaubitz wrote:
> Hi Jean-Michel,
> 
> On Thu, 2025-06-05 at 08:24 +0200, Jean-Michel Hautbois wrote:
>> I tried to patch gcc-13 with this BIGGEST_ALIGNMENT set to 64. I am
>> using buildroot+uclibc-ng on a Coldfire (mcf54418).
> 
> Thanks a lot for testing! Such contributions are highly appreciated.
> 
>> Everything build fine, except the kernel:
>>
>> In function ‘siginfo_build_tests’,
>>       inlined from ‘restore_sigcontext’ at arch/m68k/kernel/signal.c:684:2,
>>       inlined from ‘do_sigreturn’ at arch/m68k/kernel/signal.c:775:9:
>> ././include/linux/compiler_types.h:542:45: error: call to
>> ‘__compiletime_assert_351’ declared with attribute error: BUILD_BUG_ON
>> failed: offsetof(siginfo_t, si_lower) != 0x12
>>     542 |         _compiletime_assert(condition, msg,
>> __compiletime_assert_, __COUNTER__)
>>         |                                             ^
>> ././include/linux/compiler_types.h:523:25: note: in definition of macro
>> ‘__compiletime_assert’
>>     523 |                         prefix ## suffix();
>>           \
>>         |                         ^~~~~~
>> ././include/linux/compiler_types.h:542:9: note: in expansion of macro
>> ‘_compiletime_assert’
>>     542 |         _compiletime_assert(condition, msg,
>> __compiletime_assert_, __COUNTER__)
>>         |         ^~~~~~~~~~~~~~~~~~~
>> ./include/linux/build_bug.h:39:37: note: in expansion of macro
>> ‘compiletime_assert’
>>      39 | #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond),
>> msg)
>>         |                                     ^~~~~~~~~~~~~~~~~~
>> ./include/linux/build_bug.h:50:9: note: in expansion of macro
>> ‘BUILD_BUG_ON_MSG’
>>      50 |         BUILD_BUG_ON_MSG(condition, "BUILD_BUG_ON failed: "
>> #condition)
>>         |         ^~~~~~~~~~~~~~~~
>> arch/m68k/kernel/signal.c:621:9: note: in expansion of macro ‘BUILD_BUG_ON’
>>     621 |         BUILD_BUG_ON(offsetof(siginfo_t, si_lower) != 0x12);
>>         |         ^~~~~~~~~~~~
>> make[5]: *** [scripts/Makefile.build:207: arch/m68k/kernel/signal.o] Error 1
>> make[4]: *** [scripts/Makefile.build:465: arch/m68k/kernel] Error 2
>> make[4]: *** Waiting for unfinished jobs....
>>
>> This is a 6.14.
>> Any idea about this ?
> 
> It looks like this check needs to be patched:
> 
> 	BUILD_BUG_ON(offsetof(siginfo_t, si_lower) != 0x12);
> 
> The source code in arch/m68k/kernel/signal.c contains a lot of hard-wired offsets
> which will probably have to be adjusted.
> 
> You can try changing 0x12 to 0x14 and see if that fixes it.

I had to change three offsets:
diff --git a/arch/m68k/kernel/signal.c b/arch/m68k/kernel/signal.c
index e628b859ef21..5b8ef98565c2 100644
--- a/arch/m68k/kernel/signal.c
+++ b/arch/m68k/kernel/signal.c
@@ -618,11 +618,11 @@ static inline void siginfo_build_tests(void)
         BUILD_BUG_ON(offsetof(siginfo_t, si_addr_lsb) != 0x10);

         /* _sigfault._addr_bnd */
-       BUILD_BUG_ON(offsetof(siginfo_t, si_lower) != 0x12);
-       BUILD_BUG_ON(offsetof(siginfo_t, si_upper) != 0x16);
+       BUILD_BUG_ON(offsetof(siginfo_t, si_lower) != 0x14);
+       BUILD_BUG_ON(offsetof(siginfo_t, si_upper) != 0x18);

         /* _sigfault._addr_pkey */
-       BUILD_BUG_ON(offsetof(siginfo_t, si_pkey) != 0x12);
+       BUILD_BUG_ON(offsetof(siginfo_t, si_pkey) != 0x14);

         /* _sigfault._perf */
         BUILD_BUG_ON(offsetof(siginfo_t, si_perf_data) != 0x10);
-- 
2.39.5

The kernel is booting, so, I suppose it is working :-).
Now, I can't send a patch fixing the offsets like that, as it depends on 
the BIGGEST_ALIGNMENT value...

Thanks,
JM

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

Hi Jean-Michael,

On Thu, 2025-06-05 at 08:50 +0200, Jean-Michel Hautbois wrote:
> 
> I had to change three offsets:
> diff --git a/arch/m68k/kernel/signal.c b/arch/m68k/kernel/signal.c
> index e628b859ef21..5b8ef98565c2 100644
> --- a/arch/m68k/kernel/signal.c
> +++ b/arch/m68k/kernel/signal.c
> @@ -618,11 +618,11 @@ static inline void siginfo_build_tests(void)
>          BUILD_BUG_ON(offsetof(siginfo_t, si_addr_lsb) != 0x10);
> 
>          /* _sigfault._addr_bnd */
> -       BUILD_BUG_ON(offsetof(siginfo_t, si_lower) != 0x12);
> -       BUILD_BUG_ON(offsetof(siginfo_t, si_upper) != 0x16);
> +       BUILD_BUG_ON(offsetof(siginfo_t, si_lower) != 0x14);
> +       BUILD_BUG_ON(offsetof(siginfo_t, si_upper) != 0x18);
> 
>          /* _sigfault._addr_pkey */
> -       BUILD_BUG_ON(offsetof(siginfo_t, si_pkey) != 0x12);
> +       BUILD_BUG_ON(offsetof(siginfo_t, si_pkey) != 0x14);
> 
>          /* _sigfault._perf */
>          BUILD_BUG_ON(offsetof(siginfo_t, si_perf_data) != 0x10);

OK, great. This is valuable information.

> The kernel is booting, so, I suppose it is working :-).
> Now, I can't send a patch fixing the offsets like that, as it depends on
> the BIGGEST_ALIGNMENT value...

Yes, please send a patch. I don't expect it to be accepted immediately, but
it will help us spur a discussion on the necessary changes in the kernel.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Geert Uytterhoeven]

Hi Adrian,

On Thu, 5 Jun 2025 at 08:56, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On Thu, 2025-06-05 at 08:50 +0200, Jean-Michel Hautbois wrote:
> > I had to change three offsets:
> > diff --git a/arch/m68k/kernel/signal.c b/arch/m68k/kernel/signal.c
> > index e628b859ef21..5b8ef98565c2 100644
> > --- a/arch/m68k/kernel/signal.c
> > +++ b/arch/m68k/kernel/signal.c
> > @@ -618,11 +618,11 @@ static inline void siginfo_build_tests(void)
> >          BUILD_BUG_ON(offsetof(siginfo_t, si_addr_lsb) != 0x10);
> >
> >          /* _sigfault._addr_bnd */
> > -       BUILD_BUG_ON(offsetof(siginfo_t, si_lower) != 0x12);
> > -       BUILD_BUG_ON(offsetof(siginfo_t, si_upper) != 0x16);
> > +       BUILD_BUG_ON(offsetof(siginfo_t, si_lower) != 0x14);
> > +       BUILD_BUG_ON(offsetof(siginfo_t, si_upper) != 0x18);
> >
> >          /* _sigfault._addr_pkey */
> > -       BUILD_BUG_ON(offsetof(siginfo_t, si_pkey) != 0x12);
> > +       BUILD_BUG_ON(offsetof(siginfo_t, si_pkey) != 0x14);
> >
> >          /* _sigfault._perf */
> >          BUILD_BUG_ON(offsetof(siginfo_t, si_perf_data) != 0x10);
>
> OK, great. This is valuable information.
>
> > The kernel is booting, so, I suppose it is working :-).
> > Now, I can't send a patch fixing the offsets like that, as it depends on
> > the BIGGEST_ALIGNMENT value...
>
> Yes, please send a patch. I don't expect it to be accepted immediately, but
> it will help us spur a discussion on the necessary changes in the kernel.

It will be NAKed, because it would break the ABI.

Thank you for providing solid evidence that changing the default
alignment in the compiler will break the ABI, and is thus unacceptable.
(I wanted to test-compile all uapi headers to find differences, but
ran into many headers not being self-contained, or causing conflicts).

Feel free to start arch/m68k32/ to work around this ;-)

BTW, looking into the history of __ADDR_BND_PKEY_PAD() (which is
overkill on m68k, as __alignof__(void *) = 2, but might still be useful
for anyone wanting to revive CRIS support ;-), I ran into Andreas'
explanation why the minimal alignment is still 2 bytes:
https://lore.kernel.org/all/87y3i442w1.fsf@linux-m68k.org/.
(TL;DR: SunOS started on 68000).

Gr{oetje,eeting}s,

                        Geert


--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

Hello Geert,

On Thu, 2025-06-05 at 09:16 +0200, Geert Uytterhoeven wrote:
> > Yes, please send a patch. I don't expect it to be accepted immediately, but
> > it will help us spur a discussion on the necessary changes in the kernel.
> 
> It will be NAKed, because it would break the ABI.

No problem. We'll carry the patches downstream then. I'm not going to change
my mind about this because the alternative would be to just let the port die.

> Thank you for providing solid evidence that changing the default
> alignment in the compiler will break the ABI, and is thus unacceptable.

And who cares about breaking the ABI in a retro-computing platform except
for the few people actively maintaining it? This argument only really makes
sense when talking about something that has commercial relevance or a relevant
user base.

> (I wanted to test-compile all uapi headers to find differences, but
> ran into many headers not being self-contained, or causing conflicts).
> 
> Feel free to start arch/m68k32/ to work around this ;-)

Nope, we're just going to carry patches downstream and I'll just ignore people
that actively want to obstruct fixing a long-time problem on m68k with the weak
argument that it would break Linux binaries from 1993 running on a modern kernel.

This isn't a use case I care about.

> BTW, looking into the history of __ADDR_BND_PKEY_PAD() (which is
> overkill on m68k, as __alignof__(void *) = 2, but might still be useful
> for anyone wanting to revive CRIS support ;-), I ran into Andreas'
> explanation why the minimal alignment is still 2 bytes:
> https://lore.kernel.org/all/87y3i442w1.fsf@linux-m68k.org/.

This post just proves that it's always a bad idea to keep historical burden
instead of fixing it.

Again, can you please bring up a convincing argument why it would be a hard
problem to break the ABI for Linux on 40-year-old hardware? And who would be
affected by it?

The ABI isn't set in stone and if need to break it to fix fundamental problems,
then be it. They even broke the ABI on a production architecture (s390) back
in 2014 [1] and apparently we were all able to move on after this.

Adrian

> [1] https://lwn.net/Articles/605607/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Anders Magnusson]

Just curious; does not Linux use the processor-specific flagging in the 
binary that can tell whether it's 16- or 32-bit-aligned (and handle it 
thereafter)?

NetBSD changed VAX from 1k to 4k pages quite some time ago, and to be 
able to use both we added a new id for 4k pages.

-- R

Den 2025-06-05 kl. 09:36, skrev John Paul Adrian Glaubitz:
> Hello Geert,
>
> On Thu, 2025-06-05 at 09:16 +0200, Geert Uytterhoeven wrote:
>>> Yes, please send a patch. I don't expect it to be accepted immediately, but
>>> it will help us spur a discussion on the necessary changes in the kernel.
>> It will be NAKed, because it would break the ABI.
> No problem. We'll carry the patches downstream then. I'm not going to change
> my mind about this because the alternative would be to just let the port die.
>
>> Thank you for providing solid evidence that changing the default
>> alignment in the compiler will break the ABI, and is thus unacceptable.
> And who cares about breaking the ABI in a retro-computing platform except
> for the few people actively maintaining it? This argument only really makes
> sense when talking about something that has commercial relevance or a relevant
> user base.
>
>> (I wanted to test-compile all uapi headers to find differences, but
>> ran into many headers not being self-contained, or causing conflicts).
>>
>> Feel free to start arch/m68k32/ to work around this ;-)
> Nope, we're just going to carry patches downstream and I'll just ignore people
> that actively want to obstruct fixing a long-time problem on m68k with the weak
> argument that it would break Linux binaries from 1993 running on a modern kernel.
>
> This isn't a use case I care about.
>
>> BTW, looking into the history of __ADDR_BND_PKEY_PAD() (which is
>> overkill on m68k, as __alignof__(void *) = 2, but might still be useful
>> for anyone wanting to revive CRIS support ;-), I ran into Andreas'
>> explanation why the minimal alignment is still 2 bytes:
>> https://lore.kernel.org/all/87y3i442w1.fsf@linux-m68k.org/.
> This post just proves that it's always a bad idea to keep historical burden
> instead of fixing it.
>
> Again, can you please bring up a convincing argument why it would be a hard
> problem to break the ABI for Linux on 40-year-old hardware? And who would be
> affected by it?
>
> The ABI isn't set in stone and if need to break it to fix fundamental problems,
> then be it. They even broke the ABI on a production architecture (s390) back
> in 2014 [1] and apparently we were all able to move on after this.
>
> Adrian
>
>> [1] https://lwn.net/Articles/605607/

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Martin Husemann]

On Thu, Jun 05, 2025 at 10:49:08AM +0200, Anders Magnusson wrote:
> Just curious; does not Linux use the processor-specific flagging in the
> binary that can tell whether it's 16- or 32-bit-aligned (and handle it
> thereafter)?
> 
> NetBSD changed VAX from 1k to 4k pages quite some time ago, and to be able
> to use both we added a new id for 4k pages.

Or add an ELF note to all new binaries - we do that on sparc64 to mark
the compiler memory model used and give all binaries w/o the note
(or a note that it is using "medlow") a different VA memory layout (to
keep shared libs in range of the instructions used there, but defeating
most of ASLR).

Example:

 > file ls  
ls: ELF 64-bit MSB pie executable, SPARC V9, relaxed memory ordering, version 1 (SYSV), dynamically linked, interpreter /libexec/ld.elf_so, for NetBSD 10.99.14, compiler model: medmid, not stripped

 > readelf -n ls

Displaying notes found in: .note.netbsd.ident
  Owner                Data size        Description
  NetBSD                0x00000004      IDENT 1099001400 (10.99.14)

Displaying notes found in: .note.netbsd.pax
  Owner                Data size        Description
  NetBSD                0x00000004      PaX <>

Displaying notes found in: .note.netbsd.mcmodel
  Owner                Data size        Description
  NetBSD        0x00000008      Unknown note type: (0x00000006)


The kernel finds these at exec/load time and sets a flag in the process
structure, and the (very few) places where it is important test for it.

This makes old installations compatible and old binaries using old
shared libs too, but you still can not mix shared libs (so you may have
to bump libc major if you really want to keep everything compatible).

Martin

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Geert Uytterhoeven]

On Thu, 5 Jun 2025 at 12:33, Martin Husemann <martin@duskware.de> wrote:
> On Thu, Jun 05, 2025 at 10:49:08AM +0200, Anders Magnusson wrote:
> > Just curious; does not Linux use the processor-specific flagging in the
> > binary that can tell whether it's 16- or 32-bit-aligned (and handle it
> > thereafter)?
> >
> > NetBSD changed VAX from 1k to 4k pages quite some time ago, and to be able
> > to use both we added a new id for 4k pages.
>
> Or add an ELF note to all new binaries - we do that on sparc64 to mark
> the compiler memory model used and give all binaries w/o the note
> (or a note that it is using "medlow") a different VA memory layout (to
> keep shared libs in range of the instructions used there, but defeating
> most of ASLR).

Op MIPS N32 (EF_MIPS_ABI2), which also uses different syscall numbers.
Then the kernel has to take care of the translation.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Finn Thain]

On Thu, 5 Jun 2025, John Paul Adrian Glaubitz wrote:

> > (I wanted to test-compile all uapi headers to find differences, but 
> > ran into many headers not being self-contained, or causing conflicts).
> > 
> > Feel free to start arch/m68k32/ to work around this ;-)
> 
> Nope, we're just going to carry patches downstream and I'll just ignore 
> people that actively want to obstruct fixing a long-time problem on m68k 
> with the weak argument that it would break Linux binaries from 1993 
> running on a modern kernel.
> 
> This isn't a use case I care about.
> 

Whereas, the ability to use old binaries is proof that we care about rule 
#1 don't break userspace.

Having said that, I agree that there is scope for a better ABI. 
Users/developers will eventually want solutions to the Y2038 problem. ISTR 
they once wanted an address register dedicated to the thread storage area. 
And prior to that, some wanted binaries that could more easily run on both 
Coldfire and 680x0 hardware. And apparently there's baggage in the 
userspace interfaces that could be dropped.

NXP presently sells a soft-core Coldfire implementation which makes me 
wonder what those engineers can tell us about deficiencies in our ABI, in 
their experience.

> > BTW, looking into the history of __ADDR_BND_PKEY_PAD() (which is 
> > overkill on m68k, as __alignof__(void *) = 2, but might still be 
> > useful for anyone wanting to revive CRIS support ;-), I ran into 
> > Andreas' explanation why the minimal alignment is still 2 bytes: 
> > https://lore.kernel.org/all/87y3i442w1.fsf@linux-m68k.org/.
> 
> This post just proves that it's always a bad idea to keep historical 
> burden instead of fixing it.
> 
> Again, can you please bring up a convincing argument why it would be a 
> hard problem to break the ABI for Linux on 40-year-old hardware? And who 
> would be affected by it?
> 

I think Arnd already answered those questions: 
https://lore.kernel.org/all/383faec7-8987-4680-920d-8f802e1bea34@app.fastmail.com/

Moreover, "what's wrong with my idea" is the wrong question. The right 
question is, "what's wrong with my patches?"

> The ABI isn't set in stone and if need to break it to fix fundamental 
> problems, then be it.

Well, that's a value judgement you're free to make regarding your systems. 
It's easy to find fault in other peoples' systems but it's also pointless. 
It won't get us closer to a consensus that will hold for another 30 years.

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Fri, 2025-06-06 at 09:01 +0200, Geert Uytterhoeven wrote:
> On Thu, 5 Jun 2025 at 12:33, Martin Husemann <martin@duskware.de> wrote:
> > On Thu, Jun 05, 2025 at 10:49:08AM +0200, Anders Magnusson wrote:
> > > Just curious; does not Linux use the processor-specific flagging in the
> > > binary that can tell whether it's 16- or 32-bit-aligned (and handle it
> > > thereafter)?
> > > 
> > > NetBSD changed VAX from 1k to 4k pages quite some time ago, and to be able
> > > to use both we added a new id for 4k pages.
> > 
> > Or add an ELF note to all new binaries - we do that on sparc64 to mark
> > the compiler memory model used and give all binaries w/o the note
> > (or a note that it is using "medlow") a different VA memory layout (to
> > keep shared libs in range of the instructions used there, but defeating
> > most of ASLR).
> 
> Op MIPS N32 (EF_MIPS_ABI2), which also uses different syscall numbers.
> Then the kernel has to take care of the translation.

Why not just add a kernel option to allow building the m68k kernel with 4 bytes
alignment? Anyone who still wants to keep 2 bytes alignment can continue to do
so.

The same would apply for gcc and glibc. Both can offer a configure option to set
the default alignment to 4 bytes. This way everyone who wants to continue using
2 bytes alignment can continue to do so without further ado.

And anyone else who wants to switch alignment, can just do so.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Fri, 2025-06-06 at 20:20 +1000, Finn Thain wrote:
> Whereas, the ability to use old binaries is proof that we care about rule 
> #1 don't break userspace.

Who is "we"? The official(!) ABI says that pointers are supposed to be aligned
with 4 bytes, not 2 bytes. It's the current implementation that violates the
ABI, not what I want to achieve which is make Linux/m68k adhere to the official
specification.

Furthermore, we're still talking about a hobbyist platform here which hasn't been
in production use for more than ten years. It doesn't really matter whether we break
the ABI or not.

And it's not like there isn't strong case for making this change. As I have tirelessly
explained, the current port with 2 bytes alignment is simply no longer feasible since
an increasing number of packages either require 4 bytes alignment or require Rust.

These include more and more fundamental packages such as coreutils, the kernel or various
Python packages such as python-cryptography. It's simply not an option to continue on
the current path as it has become a dead-end.

I don't see the point in maintaining something that becomes increasingly useless because
more and more packages are no longer buildable. If kernel people think that usefulness
is already established when you can boot busybox and type some commands, then you might
be able to continue on that path.

But I'm a distribution maintainer and distributions consist of way more packages than
the kernel, busybox and the toolchain. And even the toolchain doesn't even fully build
on Linux/m68k anymore because it requires 4 bytes alignment for LLVM, gccgo and mold.

So, whatever we currently have that we would break compatibility with, I do not think
that it's worth the effort to keep it alive.

> Having said that, I agree that there is scope for a better ABI. 
> Users/developers will eventually want solutions to the Y2038 problem.

This has already been addressed in Debian and surprisingly, no started a fight over it.

I don't see why it shouldn't be possible to do the same with the alignment. We have the
full source available. We can rebuild everything and I have already created an initial
4 bytes alignment bootstrap with the help of Helmut Grohne's fantastic rebootstrap project.

So far, it works as expected and multiple packages that previously didn't build because
of the 2 bytes alignment, just built fine and without any further patches. This is
exactly what I want.

> > > BTW, looking into the history of __ADDR_BND_PKEY_PAD() (which is 
> > > overkill on m68k, as __alignof__(void *) = 2, but might still be 
> > > useful for anyone wanting to revive CRIS support ;-), I ran into 
> > > Andreas' explanation why the minimal alignment is still 2 bytes: 
> > > https://lore.kernel.org/all/87y3i442w1.fsf@linux-m68k.org/.
> > 
> > This post just proves that it's always a bad idea to keep historical 
> > burden instead of fixing it.
> > 
> > Again, can you please bring up a convincing argument why it would be a 
> > hard problem to break the ABI for Linux on 40-year-old hardware? And who 
> > would be affected by it?
> > 
> 
> I think Arnd already answered those questions: 
> https://lore.kernel.org/all/383faec7-8987-4680-920d-8f802e1bea34@app.fastmail.com/
> 
> Moreover, "what's wrong with my idea" is the wrong question. The right 
> question is, "what's wrong with my patches?"

Finn, again, you haven't contributed any useful input to help alleviate the
original problem. I don't really understand why you think it's acceptable to
constantly bombard my efforts with such comments. How does this help?

Please re-read what John Klos wrote on this matter as he already pointed out
why your comments to this discussion aren't moving us any further here.

> > The ABI isn't set in stone and if need to break it to fix fundamental 
> > problems, then be it.
> 
> Well, that's a value judgement you're free to make regarding your systems. 
> It's easy to find fault in other peoples' systems but it's also pointless. 
> It won't get us closer to a consensus that will hold for another 30 years.

I'm not seeing how violating the official ABI was ever agreed upon. It seems
that Andreas took this decision in his own hand while the NetBSD people were
courageous enough to switch the default alignment when switching the executable
format.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Andreas Schwab]

On Jun 07 2025, John Paul Adrian Glaubitz wrote:

> Who is "we"? The official(!) ABI says that pointers are supposed to be aligned
> with 4 bytes, not 2 bytes.

No, that is wrong.  The official ABI uses 2 byte alignment.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Anders Magnusson]

Den 2025-06-07 kl. 11:58, skrev Andreas Schwab:
> On Jun 07 2025, John Paul Adrian Glaubitz wrote:
>
>> Who is "we"? The official(!) ABI says that pointers are supposed to be aligned
>> with 4 bytes, not 2 bytes.
> No, that is wrong.  The official ABI uses 2 byte alignment.
The paper copy of the "System V Application Binary Interface" for 68000 
that I have here says that all pointers should be aligned 4 bytes 
(figure 3-1).  Nothing else.

-- R

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Andreas Schwab]

On Jun 07 2025, Anders Magnusson wrote:

> The paper copy of the "System V Application Binary Interface" for 68000
> that I have here says that all pointers should be aligned 4 bytes (figure
> 3-1).  Nothing else.

And how is that relevant?

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Anders Magnusson]

Den 2025-06-07 kl. 13:11, skrev Andreas Schwab:
> On Jun 07 2025, Anders Magnusson wrote:
>
>> The paper copy of the "System V Application Binary Interface" for 68000
>> that I have here says that all pointers should be aligned 4 bytes (figure
>> 3-1).  Nothing else.
> And how is that relevant?
Well, were we not discussing the ELF specification for 68k?

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Sat, 2025-06-07 at 11:58 +0200, Andreas Schwab wrote:
> On Jun 07 2025, John Paul Adrian Glaubitz wrote:
> 
> > Who is "we"? The official(!) ABI says that pointers are supposed to be aligned
> > with 4 bytes, not 2 bytes.
> 
> No, that is wrong.  The official ABI uses 2 byte alignment.

The official AT&T SysV ABI states that pointers must be aligned with 4 bytes.

See: https://people.debian.org/~glaubitz/m68k-sysv-abi.pdf (page 29)

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Sat, 2025-06-07 at 13:11 +0200, Andreas Schwab wrote:
> On Jun 07 2025, Anders Magnusson wrote:
> 
> > The paper copy of the "System V Application Binary Interface" for 68000
> > that I have here says that all pointers should be aligned 4 bytes (figure
> > 3-1).  Nothing else.
> 
> And how is that relevant?

That's an odd question to ask. You can't argue with the ABI specification when
you can just make up your own one. And it's not that I haven't done extensive
testing for that.

My tests have shown that Amiga Unix based on SVR4 using ELF binaries uses 4 bytes
alignment. If that isn't a representation of the official ABI then I don't know
what is.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Sat, 2025-06-07 at 14:55 +0200, Anders Magnusson wrote:
> Den 2025-06-07 kl. 13:11, skrev Andreas Schwab:
> > On Jun 07 2025, Anders Magnusson wrote:
> > 
> > > The paper copy of the "System V Application Binary Interface" for 68000
> > > that I have here says that all pointers should be aligned 4 bytes (figure
> > > 3-1).  Nothing else.
> > And how is that relevant?
>
> Well, were we not discussing the ELF specification for 68k?

It's odd that Andreas would claim that an alignment of 2 bytes is the official
ABI when he himself that admitted himself that the 2 bytes is a mistake, i.e.
wrong [1].

But let's get back to my proposal: I would suggest adding an option to the Linux
kernel, glibc and gcc to configure them with 4 bytes alignment. Since that adheres
to the official SVR4 specification, we could use the appropriate moniker for that.

Providing users with options is usually the best way to deal with conflicts.

Adrian

> [1] https://lore.kernel.org/all/87y3i442w1.fsf@linux-m68k.org/

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Andreas Schwab]

On Jun 07 2025, John Paul Adrian Glaubitz wrote:

> On Sat, 2025-06-07 at 11:58 +0200, Andreas Schwab wrote:
>> On Jun 07 2025, John Paul Adrian Glaubitz wrote:
>> 
>> > Who is "we"? The official(!) ABI says that pointers are supposed to be aligned
>> > with 4 bytes, not 2 bytes.
>> 
>> No, that is wrong.  The official ABI uses 2 byte alignment.
>
> The official AT&T SysV ABI states that pointers must be aligned with 4 bytes.

If you want to use AT&T System V, you are free to do so.  But Linux is
not AT&T System V.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Sat, 2025-06-07 at 16:38 +0200, Andreas Schwab wrote:
> On Jun 07 2025, John Paul Adrian Glaubitz wrote:
> 
> > On Sat, 2025-06-07 at 11:58 +0200, Andreas Schwab wrote:
> > > On Jun 07 2025, John Paul Adrian Glaubitz wrote:
> > > 
> > > > Who is "we"? The official(!) ABI says that pointers are supposed to be aligned
> > > > with 4 bytes, not 2 bytes.
> > > 
> > > No, that is wrong.  The official ABI uses 2 byte alignment.
> > 
> > The official AT&T SysV ABI states that pointers must be aligned with 4 bytes.
> 
> If you want to use AT&T System V, you are free to do so.  But Linux is
> not AT&T System V.

It kinda is:

glaubitz@esk:~/gcc/gcc/config/m68k$ grep -i svr4 linux.h
   m68k/SVR4 allow d0, a0, or fp0 as return registers, for integral,
   FUNCTION_DECL; otherwise, FUNC is 0.  For m68k/SVR4 generate the
   For m68k/SVR4 look for integer values in d0, pointer values in d0
/* For m68k SVR4, structures are returned using the reentrant
   For m68k/SVR4, some types (doubles for example) are aligned on 8 byte
glaubitz@esk:~/gcc/gcc/config/m68k$

What I don't understand: What's the deal with changing the ABI now? The people
who object the change still haven't come with a convincing argument so far except
for the circular reasoning that you cannot change the ABI because that would change
the ABI.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Andreas Schwab]

On Jun 07 2025, John Paul Adrian Glaubitz wrote:

> you cannot change the ABI because that would change the ABI.

That's the fundamental property of an ABI.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Sat, 2025-06-07 at 17:03 +0200, Andreas Schwab wrote:
> On Jun 07 2025, John Paul Adrian Glaubitz wrote:
> 
> > you cannot change the ABI because that would change the ABI.
> 
> That's the fundamental property of an ABI.

Not if the ABI was made-up by yourself ;-).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Andreas Schwab]

On Jun 07 2025, John Paul Adrian Glaubitz wrote:

> On Sat, 2025-06-07 at 17:03 +0200, Andreas Schwab wrote:
>> On Jun 07 2025, John Paul Adrian Glaubitz wrote:
>> 
>> > you cannot change the ABI because that would change the ABI.
>> 
>> That's the fundamental property of an ABI.
>
> Not if the ABI was made-up by yourself ;-).

No, I didn't.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Sat, 2025-06-07 at 17:20 +0200, Andreas Schwab wrote:
> On Jun 07 2025, John Paul Adrian Glaubitz wrote:
> 
> > On Sat, 2025-06-07 at 17:03 +0200, Andreas Schwab wrote:
> > > On Jun 07 2025, John Paul Adrian Glaubitz wrote:
> > > 
> > > > you cannot change the ABI because that would change the ABI.
> > > 
> > > That's the fundamental property of an ABI.
> > 
> > Not if the ABI was made-up by yourself ;-).
> 
> No, I didn't.

»When I implemented ELF support for m68k-linux I wanted to follow the SVR4
 ABI (which has 32-bit alignment), but there were too many UAPI structures
 (esp. struct stat) that would have become incompatible (it would have made
 it impossible to run ELF binaries on an a.out kernel or vice-versa), so I
 had to keep the historical mistake.«

Source: https://lore.kernel.org/all/87y3i442w1.fsf@linux-m68k.org/

It was very obviously your decision to use 2 byte alignment even though it
was against the official SVR4 ABI ;-).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Andreas Schwab]

On Jun 07 2025, John Paul Adrian Glaubitz wrote:

> It was very obviously your decision to use 2 byte alignment even though it
> was against the official SVR4 ABI ;-).

No, I followed the official ABI.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Klos]

>> It was very obviously your decision to use 2 byte alignment even though it
>> was against the official SVR4 ABI ;-).
>
> No, I followed the official ABI.

People here are clearly talking about the Unix SVR4 ABI. It's not clever 
to start talking about the Linux ABI without saying you're now talking 
about something other than what everyone else was talking about.

I've suggested rolling this in to the ABI change that'll address Y2038. I 
think, although you're not abundantly clear, that you advocate for that 
change to not be made, too. Is that the case? Should Linux/m68k just 
have the wrong time after 2038? Please be clear.

If you think that change is OK, then is there good technical reasoning you 
can think of to not roll this change in at the same time?

John

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Andreas Schwab]

On Jun 07 2025, John Klos wrote:

> I've suggested rolling this in to the ABI change that'll address Y2038. I
> think, although you're not abundantly clear, that you advocate for that
> change to not be made, too.

There is no change to be made.  All support for 64-bit time_t is already
in place.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Jason Thorpe]

> On Jun 7, 2025, at 2:58 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> 
> On Jun 07 2025, John Paul Adrian Glaubitz wrote:
> 
>> Who is "we"? The official(!) ABI says that pointers are supposed to be aligned
>> with 4 bytes, not 2 bytes.
> 
> No, that is wrong.  The official ABI uses 2 byte alignment.

https://m680x0.github.io/ref/sysv-m68k-abi-part1.pdf

Figure 3-1 says 4-byte alignment for pointers.  Please show the document that says 2-byte.

-- thorpej

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Andreas Schwab]

On Jun 07 2025, Jason Thorpe wrote:

> https://m680x0.github.io/ref/sysv-m68k-abi-part1.pdf

How is that relevant?

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Jason Thorpe]

> On Jun 7, 2025, at 2:43 PM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> 
> On Jun 07 2025, Jason Thorpe wrote:
> 
>> https://m680x0.github.io/ref/sysv-m68k-abi-part1.pdf
> 
> How is that relevant?

It’s literally the ABI we’re all discussing.

-- thorpej

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Finn Thain]

On Sat, 7 Jun 2025, John Paul Adrian Glaubitz wrote:

> On Fri, 2025-06-06 at 20:20 +1000, Finn Thain wrote:
> > Whereas, the ability to use old binaries is proof that we care about 
> > rule #1 don't break userspace.
> 
> Who is "we"?

AFAICT, it's essentially everyone who contributes patches at the userspace 
interfaces.

> The official(!) ABI says that pointers are supposed to be aligned with 4 
> bytes, not 2 bytes. It's the current implementation that violates the 
> ABI, not what I want to achieve which is make Linux/m68k adhere to the 
> official specification.
> 

You've mistaken the flock for the shepherd. And the map for the terrain(!)

But once you've been around the block a few times, you'll come to 
understand that standards lag best practice. They don't lead.

And then maybe you'll stop moving in circles.

Also, you've misunderstood he relationship between Linux and Unix. There 
is a long and colorful history there. You should look into it. 
https://en.wikipedia.org/wiki/SVR4#SVR6_(cancelled)

> Furthermore, we're still talking about a hobbyist platform here which 
> hasn't been in production use for more than ten years. It doesn't really 
> matter whether we break the ABI or not.
> 

By the same argument, since Debian is comprised of volunteers and 
hobbyists, it can be ignored by corporate-sponsored organizations, such as 
the Rust Foundation, and by upstream maintainers employed by for-profit 
companies. Yet they don't ignore us. Why do you think that is?

> And it's not like there isn't strong case for making this change. As I 
> have tirelessly explained, the current port with 2 bytes alignment is 
> simply no longer feasible since an increasing number of packages either 
> require 4 bytes alignment or require Rust.
> 
> These include more and more fundamental packages such as coreutils, the 
> kernel or various Python packages such as python-cryptography. It's 
> simply not an option to continue on the current path as it has become a 
> dead-end.
> 

Every CPU architecture is a dead end. This observation is as old as 
Moore's Law.

> I don't see the point in maintaining something that becomes increasingly 
> useless because more and more packages are no longer buildable.

That's because you still haven't identified those packages in the Debian 
archive which actually need porting.

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Martin Husemann]

On Sun, Jun 08, 2025 at 11:10:38AM +1000, Finn Thain wrote:
> 
> On Sat, 7 Jun 2025, John Paul Adrian Glaubitz wrote:
> 
> > On Fri, 2025-06-06 at 20:20 +1000, Finn Thain wrote:
> > > Whereas, the ability to use old binaries is proof that we care about 
> > > rule #1 don't break userspace.
> > 
> > Who is "we"?
> 
> AFAICT, it's essentially everyone who contributes patches at the userspace 
> interfaces.

Since this thread also hit a non-Linux lists I just want to point
out that we (as in: NetBSD) did not break userland when adapting the
SVR4 ABI including different alignment for ELF.

I just tested it with some original 1994 NetBSD 1.0 / amiga binaries
on an amiga running NetBSD-current as of earlier today.

I started with an empty ~/aout_test directory.

I slightly shortened the lengthy and boring download sequence in the log
(back then distributions were optimized for transport via floopies - duh!)

--8<--
[~/aout_test] martin@amiga > uname -a
NetBSD amiga.aprisoft.de 10.99.14 NetBSD 10.99.14 (GENERIC) #6: Sun Jun  8 08:11:46 CEST 2025  martin@seven-days-to-the-wolves.aprisoft.de:/work/src/sys/arch/amiga/compile/GENERIC amiga
[~/aout_test] martin@amiga > file /bin/ls
/bin/ls: ELF 32-bit MSB pie executable, Motorola m68k, 68020, version 1 (SYSV), dynamically linked, interpreter /libexec/ld.elf_so, for NetBSD 10.99.14, not stripped
[~/aout_test] martin@amiga > ftp http://archive.netbsd.org/pub/NetBSD-archive/Ne \btBSD-1.0/amiga/binary/base10/base10.aa
Trying [2a04:4e42:8e::262]:80 ...
ftp: Can't connect to `2a04:4e42:8e::262:80': No route to host
Trying 146.75.117.6:80 ...
Requesting http://archive.netbsd.org/pub/NetBSD-archive/NetBSD-1.0/amiga/binary/base10/base10.aa
[..]
[~/aout_test] martin@amiga > ftp http://archive.netbsd.org/pub/NetBSD-archive/Ne \rtBSD-1.0/amiga/binary/base10/base10.ag\b^[[Kh
Trying [2a04:4e42:8e::262]:80 ...
ftp: Can't connect to `2a04:4e42:8e::262:80': No route to host
Trying 146.75.117.6:80 ...
Requesting http://archive.netbsd.org/pub/NetBSD-archive/NetBSD-1.0/amiga/binary/base10/base10.ah
[..]
142449 bytes retrieved in 00:00 (818.21 KiB/s)
[~/aout_test] martin@amiga > su
Password:
[/data/home/martin/aout_test] amiga # cat base10.a* | tar xzpzf -
[/data/home/martin/aout_test] amiga # file bin/ls
bin/ls: a.out NetBSD/m68k demand paged executable @0x2020+T=114688+D=8192+B=7992
[/data/home/martin/aout_test] amiga # chroot . /bin/sh
# pwd
/
# ls -l
total 6436
drwxr-xr-x   2 0    0       512 Oct 21  1994 altroot
-rw-r--r--   1 205  100  901120 Oct 28  1994 base10.aa
-rw-r--r--   1 205  100  901120 Oct 28  1994 base10.ab
-rw-r--r--   1 205  100  901120 Oct 28  1994 base10.ac
-rw-r--r--   1 205  100  901120 Oct 28  1994 base10.ad
-rw-r--r--   1 205  100  901120 Oct 28  1994 base10.ae
-rw-r--r--   1 205  100  901120 Oct 28  1994 base10.af
-rw-r--r--   1 205  100  901120 Oct 28  1994 base10.ag
-rw-r--r--   1 205  100  142449 Oct 28  1994 base10.ah
drwxr-xr-x   2 0    0       512 Oct 21  1994 bin
drwxr-xr-x   3 0    0       512 Oct 21  1994 dev
drwxr-xr-x   8 0    0       512 Oct 21  1994 etc
drwxr-xr-x   2 0    0       512 Oct 21  1994 home
drwxr-xr-x   2 0    0       512 Oct 21  1994 mnt
drwxr-xr-x   2 0    0       512 Oct 21  1994 root
drwxr-xr-x   2 0    0      1024 Oct 21  1994 sbin
drwxr-xr-x   2 0    0       512 Oct 21  1994 stand
drwxrwxrwt   2 0    0       512 Oct 21  1994 tmp
drwxr-xr-x  14 0    0       512 Oct 21  1994 usr
drwxr-xr-x  18 0    0       512 Oct 21  1994 var
# uname -a
NetBSD amiga.aprisoft.de 10.99.14 NetBSD 10.99.14 (GENERIC) #6: Sun Jun  8 08:11:46 CEST 2025  martin@seven-days-to-the-wolves.aprisoft.de:/work/src/sys/arch/amiga/compile/GENERIC amiga
-->8--

So the 1.0 original release a.out binaries still work and a -current
kernel provides the right data (with old alignment and 32bit time_t)
for a stat(2) system call from 1994 using the a.out ABI.

Martin

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Sat, 2025-06-07 at 23:43 +0200, Andreas Schwab wrote:
> On Jun 07 2025, Jason Thorpe wrote:
> 
> > https://m680x0.github.io/ref/sysv-m68k-abi-part1.pdf
> 
> How is that relevant?

It's relevant because it's the official ABI and GCC suggests in it's
headers that it's SVR4-compliant on Linux.

Anyway, having this discussion isn't really leading anywhere. Let's
just agree that we disagree on what the canonical source for an ABI
specification is. You have explained your point of view and I can
understand your reasoning.

However, that doesn't help with the current situation which is that the
number of packages that fail to build from source on m68k on Linux is
increasing and it's becoming more difficult to maintain the port.

Both Debian and Gentoo want to address this problem by changing the default
alignment and both have already performed initial bootstraps with 32-bit
alignment which showed promising results.

The question now only remains what the preferred way of implementing this
change is. Since there are no other Linux distributions left that maintain
support on m68k, I think it's reasonable to expect that both Debian and Gentoo
get to have a word in this discussion, don't they?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Sun, 2025-06-08 at 11:10 +1000, Finn Thain wrote:
> > I don't see the point in maintaining something that becomes increasingly 
> > useless because more and more packages are no longer buildable.
> 
> That's because you still haven't identified those packages in the Debian 
> archive which actually need porting.

Finn, you seriously have to be kidding me. I have created a wiki page with
all the packages in question and I have posted a link to that page multiple
times.

See: https://wiki.debian.org/M68k/Alignment

Are you deliberately ignoring that?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

Hi Martin,

On Sun, 2025-06-08 at 13:47 +0200, Martin Husemann wrote:
> Since this thread also hit a non-Linux lists I just want to point
> out that we (as in: NetBSD) did not break userland when adapting the
> SVR4 ABI including different alignment for ELF.
> 
> I just tested it with some original 1994 NetBSD 1.0 / amiga binaries
> on an amiga running NetBSD-current as of earlier today.
> 
> (...)
> 
> So the 1.0 original release a.out binaries still work and a -current
> kernel provides the right data (with old alignment and 32bit time_t)
> for a stat(2) system call from 1994 using the a.out ABI.

Thanks a lot for answering this question. I was actually wondering whether
old a.out binaries would still run on current versions of NetBSD despite
the different alignment.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Sun, 2025-06-08 at 11:10 +1000, Finn Thain wrote:
> > Furthermore, we're still talking about a hobbyist platform here which 
> > hasn't been in production use for more than ten years. It doesn't really 
> > matter whether we break the ABI or not.
> > 
> 
> By the same argument, since Debian is comprised of volunteers and 
> hobbyists, it can be ignored by corporate-sponsored organizations, such as 
> the Rust Foundation, and by upstream maintainers employed by for-profit 
> companies. Yet they don't ignore us. Why do you think that is?

There is a clear difference between architectures that are actively used in
production as compared to architectures that are used for hobbyists projects
only.

We couldn't push such changes on x86_64, for example, because there is huge
worldwide userbase meaning that introducing such an ABI-breaking change would
come at a huge cost. On m68k, on the other hand, the user base is so small
and insignificant that the costs for introducing the change are negligible and
the profits for making the change strongly outweigh the disadvantages.

Please don't pretend that you don't see a significant difference here. Your
argument is dishonest and you're just trying to derail the discussion.

> > And it's not like there isn't strong case for making this change. As I 
> > have tirelessly explained, the current port with 2 bytes alignment is 
> > simply no longer feasible since an increasing number of packages either 
> > require 4 bytes alignment or require Rust.
> > 
> > These include more and more fundamental packages such as coreutils, the 
> > kernel or various Python packages such as python-cryptography. It's 
> > simply not an option to continue on the current path as it has become a 
> > dead-end.
> > 
> 
> Every CPU architecture is a dead end. This observation is as old as 
> Moore's Law.

Yes, and we all have to die some day. What's the point of bringing up this argument?

You are arguing in hyperboles which clearly shows you're not interested in a serious
discussion. Why are you even participating here?

> > I don't see the point in maintaining something that becomes increasingly 
> > useless because more and more packages are no longer buildable.
> 
> That's because you still haven't identified those packages in the Debian 
> archive which actually need porting.

I have posted that list several times already: https://wiki.debian.org/M68k/Alignment

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Finn Thain]

On Tue, 10 Jun 2025, John Paul Adrian Glaubitz wrote:

> 
> However, that doesn't help with the current situation which is that the 
> number of packages that fail to build from source on m68k on Linux is 
> increasing and it's becoming more difficult to maintain the port.
> 

Porting to m68k, with it's quirks, is more difficult for you than it was 
for your many predecessors because the Debian archive contains many more 
packages and many more lines of code than it did historically.

That's obviously the root cause of your problem, and it's also the reason 
why the Debian archive is less and less relevant, being that 680x0 systems 
still have the same number of transistors that they always did.

Now, Coldfire is a different story. But you continue to ignore it despite 
the fact your pet Debian/m68k port probably would not exist without 
Coldfire users/developers.

If there is insufficient manpower at the Debian project to patch the 
pointer abuse in Python, how could you possibly have produced the TLS 
implementation, which Codesourcery provided for its Coldfire customers, 
and which you ship?

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Finn Thain]

On Tue, 10 Jun 2025, John Paul Adrian Glaubitz wrote:

> On Sun, 2025-06-08 at 11:10 +1000, Finn Thain wrote:
> > > I don't see the point in maintaining something that becomes 
> > > increasingly useless because more and more packages are no longer 
> > > buildable.
> > 
> > That's because you still haven't identified those packages in the 
> > Debian archive which actually need porting.
> 
> Finn, you seriously have to be kidding me. I have created a wiki page 
> with all the packages in question and I have posted a link to that page 
> multiple times.
> 
> See: https://wiki.debian.org/M68k/Alignment
> 
> Are you deliberately ignoring that?
> 

I wasn't ignoring anything.

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Finn Thain]

On Tue, 10 Jun 2025, John Paul Adrian Glaubitz wrote:

> 
> There is a clear difference between architectures that are actively used 
> in production as compared to architectures that are used for hobbyists 
> projects only.
> 

Regarding the Linux/m68k effort, that claim is unsupported (and 
unsupportable, AFAICS).

If you're just talking about Debian/m68k, it's really up to you how you 
will use it to add value.

> We couldn't push such changes on x86_64, for example, because there is 
> huge worldwide userbase meaning that introducing such an ABI-breaking 
> change would come at a huge cost. On m68k, on the other hand, the user 
> base is so small and insignificant

> that the costs for introducing the change are negligible and the profits 
> for making the change strongly outweigh the disadvantages.
> 

I find cost/benefit analyses to be useful. But how will you quantify this?

Moreover, you reduced Debian/m68k to insignificance when you characterized 
all of its users as insignificant. As its maintainer, that's your 
prerogative, I suppose.

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Stan Johnson]

On 6/10/25 5:26 AM, John Paul Adrian Glaubitz wrote:
> ...
> On m68k, on the other hand, the user base is so small and insignificant 
> that the costs for introducing the change are negligible and the profits 
> for making the change strongly outweigh the disadvantages.
> ...
As part of that "small and insignificant" user community, I can say that
making things too complicated or difficult will be detrimental,
especially affecting new users.

Look at it from the perspective of a new user today on m68k systems. I
still remember the joy of being able to get a Linux 2.x kernel working
in Debian 3 on an ancient Mac IIci or SE/30. Now as the complexity
grows, I can't do much of anything useful with an old m68k Mac other
than log in (text only), edit a few files and download a few things from
the public Internet. Almost everything related to an end-user's updates
of a Debian or Gentoo distribution has to be done in QEMU or
cross-compiled. Users don't want to be berated or invited to feel bad or
lazy for wanting old things (e.g. mac-fdisk or dump/restore) to continue
working on old systems, or for wanting old programs to continue to work.
Treating users well, even if they aren't as good at programming as you
are, will make them want to be part of your team, not just part of an
insignificant user base of a product that you provide.

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Tue, 2025-06-10 at 21:04 -0600, Stan Johnson wrote:
> On 6/10/25 5:26 AM, John Paul Adrian Glaubitz wrote:
> > ...
> > On m68k, on the other hand, the user base is so small and insignificant 
> > that the costs for introducing the change are negligible and the profits 
> > for making the change strongly outweigh the disadvantages.
> > ...
> As part of that "small and insignificant" user community, I can say that
> making things too complicated or difficult will be detrimental,
> especially affecting new users.
> 
> Look at it from the perspective of a new user today on m68k systems. I
> still remember the joy of being able to get a Linux 2.x kernel working
> in Debian 3 on an ancient Mac IIci or SE/30. Now as the complexity
> grows, I can't do much of anything useful with an old m68k Mac other
> than log in (text only), edit a few files and download a few things from
> the public Internet. Almost everything related to an end-user's updates
> of a Debian or Gentoo distribution has to be done in QEMU or
> cross-compiled. Users don't want to be berated or invited to feel bad or
> lazy for wanting old things (e.g. mac-fdisk or dump/restore) to continue
> working on old systems, or for wanting old programs to continue to work.
> Treating users well, even if they aren't as good at programming as you
> are, will make them want to be part of your team, not just part of an
> insignificant user base of a product that you provide.

I'm not sure what you are trying to say here. The fact that your computer
is too slow for modern Linux distributions is unrelated to the alignment
discussion.

As previously stated, NetBSD uses 4 bytes alignment and runs fine even on
68010-based systems. In fact, using a 4 bytes alignment will actually
improve performance as it's the natural alignment the hardware uses.

The change is necessary to unbreak a lot of critical packages which are
required to continue maintaining the port. As a user, all you have to do
is reinstalling your system which I think is reasonable to expect.

If you are overwhelmed with modern software options for your old Mac, you
can just install an older Debian version and be happy with it. There is
never a guarantee that an a modern release of Debian is supported on old
hardware.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Eero Tamminen]

Hi,

On 11.6.2025 10.44, John Paul Adrian Glaubitz wrote:
> As previously stated, NetBSD uses 4 bytes alignment and runs fine even on
> 68010-based systems. In fact, using a 4 bytes alignment will actually
> improve performance as it's the natural alignment the hardware uses.

It will decrease performance if increased alignment means that something 
that fit earlier into i/d-cache, does not fit any more.

(68030 has 256 bytes, 68040 has 4 KB, and 68060 has 8 KB, of both.)

To get some numbers on this...

if you could provide vmlinuz & System.map files for both (otherwise 
identical) 2-byte & 4-byte alignment kernel builds, using kernel config 
here:
https://github.com/hatari/hatari/blob/main/tools/linux/kernel.config

I could measure the perf difference for the whole kernel boot, and if 
there are differences, profile what causes those differences.


	- Eero

PS. I will be using Hatari for that, as it has semi-cycle-accurate 
emulation for 38030, and good profiling facilities: 
https://www.hatari-emu.org/doc/debugger.html#Profiling)

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Wed, 2025-06-11 at 18:32 +0300, Eero Tamminen wrote:
> It will decrease performance if increased alignment means that something 
> that fit earlier into i/d-cache, does not fit any more.

»Control whether GCC aligns int, long, long long, float, double, and long double
 variables on a 32-bit boundary (-malign-int) or a 16-bit boundary (-mno-align-int).
 Aligning variables on 32-bit boundaries produces code that runs somewhat faster on
 processors with 32-bit busses at the expense of more memory.«

Source: https://gcc.gnu.org/onlinedocs/gcc-3.1.1/gcc/M680x0-Options.html

> (68030 has 256 bytes, 68040 has 4 KB, and 68060 has 8 KB, of both.)
> 
> To get some numbers on this...
> 
> if you could provide vmlinuz & System.map files for both (otherwise 
> identical) 2-byte & 4-byte alignment kernel builds, using kernel config 
> here:
> https://github.com/hatari/hatari/blob/main/tools/linux/kernel.config
> 
> I could measure the perf difference for the whole kernel boot, and if 
> there are differences, profile what causes those differences.

But anyway, as I have said before, I am not going to change my mind on this
and I'm already working on it. If you prefer maintaining a Linux port with
2 bytes alignment, you are free to do so. But please don't expect me to waste
my time on it.

Thanks,
Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Finn Thain]

On Wed, 11 Jun 2025, John Paul Adrian Glaubitz wrote:

> 
> I'm not sure what you are trying to say here. The fact that your 
> computer is too slow for modern Linux distributions is unrelated to the 
> alignment discussion.
> 

Sorry, Adrian, but you can't have it both ways. Either you support small 
systems or you don't. Debian's documentation says of m68k:

    This architecture covers Amigas and ATARIs having a Motorola 680x0 
    processor for x>=2; with MMU. However, the port is still active and 
    available for installation even if not a part of this official stable 
    release and might be reactivated for future releases.

https://www.debian.org/doc/manuals/debian-faq/compatibility.en.html#arches

There is no mention of fast emulators. Yet that's all you're targeting 
now.

Debian needs to fix this, so that those users/developers who are 
interested in small systems can colaborate effectively without being 
mislead.

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Thu, 2025-06-12 at 11:54 +1000, Finn Thain wrote:
> On Wed, 11 Jun 2025, John Paul Adrian Glaubitz wrote:
> 
> > 
> > I'm not sure what you are trying to say here. The fact that your 
> > computer is too slow for modern Linux distributions is unrelated to the 
> > alignment discussion.
> > 
> 
> Sorry, Adrian, but you can't have it both ways. Either you support small 
> systems or you don't. Debian's documentation says of m68k:
> 
>     This architecture covers Amigas and ATARIs having a Motorola 680x0 
>     processor for x>=2; with MMU. However, the port is still active and 
>     available for installation even if not a part of this official stable 
>     release and might be reactivated for future releases.
> 
> https://www.debian.org/doc/manuals/debian-faq/compatibility.en.html#arches
> 
> There is no mention of fast emulators. Yet that's all you're targeting 
> now.

This is old documentation, I'm not sure why you think this is an argument.

> Debian needs to fix this, so that those users/developers who are 
> interested in small systems can colaborate effectively without being 
> mislead.

Debian doesn't owe anyone anything. There a number of people who work on
Debian Ports in their free time and they are free to decide how they spend
their free time. Your arguments are really getting desperate.

It's also absurd that you think that switching the alignment to 4 bytes will
make the port considerably slower when the contrary is the case and NetBSD
developers on this thread have explained several times that they don't have
any issues with 4 bytes alignment. Heck, even Amiga Unix uses 4 bytes alignment.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Wed, 2025-06-11 at 20:16 -0700, Stefan Reinauer wrote:
> > Sorry, Adrian, but you can't have it both ways. Either you support small 
> > systems or you don't. Debian's documentation says of m68k:
> > 
> >     This architecture covers Amigas and ATARIs having a Motorola 680x0 
> >     processor for x>=2; with MMU. However, the port is still active and 
> >     available for installation even if not a part of this official stable 
> >     release and might be reactivated for future releases.
> > 
> > https://www.debian.org/doc/manuals/debian-faq/compatibility.en.html#arches
> > 
> > There is no mention of fast emulators. Yet that's all you're targeting 
> > now.
> 
> Fixing pthreads would probably go a long way. That's where we lost about half of our performance.

This may be accurate, but I'm again not sure how this is related to the discussion we're having.

Finn accuses me that I deliberately slow down Linux on m68k when all I do is continue to maintain
vanilla Debian on m68k. Modern versions of Linux being slower on slow m68k machines these days is
unfortunate, but it's not something I can be blamed for.

My goal is to keep Debian's m68k alive and healthy and one critical change to make to make this whole
effort sustainable is to switch the default alignment to 4 bytes. If we want have a smaller and faster
Debian distribution available, that is still something that can be worked in a separate project and if
users are willing to help with such an effort, I'm happy to look into it.

However, what I don't like is that multiple people in this thread dismiss my work completely with
questionable arguments and unrealistic counter-proposals when they have no clue how distributions
are maintained and how tedious it is to spin your own distribution.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Finn Thain]

On Thu, 12 Jun 2025, John Paul Adrian Glaubitz wrote:

> On Wed, 2025-06-11 at 20:16 -0700, Stefan Reinauer wrote:
> > 
> > Fixing pthreads would probably go a long way. That's where we lost 
> > about half of our performance.
> 
> This may be accurate, but I'm again not sure how this is related to the 
> discussion we're having.
> 

It's related because such changes could impact all of the C libraries and 
compiler toolchains that you wish to port. So it's an example of a burden 
created by package archive growth. 
https://lists.debian.org/debian-68k/2025/06/msg00048.html

It's also related because such an enhancement may involve an ABI break. 
That's why I mentioned threading a week ago. 
https://lists.debian.org/debian-68k/2025/06/msg00018.html

> Finn accuses me that I deliberately slow down Linux on m68k when all I 
> do is continue to maintain vanilla Debian on m68k.

Citation needed. What I have said is, Debian is bloated (in part) because 
of its dependency graph e.g. the cmake dep on Qt, which you defended. 
https://lists.debian.org/debian-68k/2025/05/msg00038.html

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Administrator @ R·V·E]

Thanks for your great hard work and efforts to mantain the various and now considered exotic architectures running Debian, Adrian!


 - R·V·E -    
 - REAL & VIRTUAL ENVIRONMENTS -           http://www.r-v-e.org


-------- Original Message --------
On 12/06/2025 09:27, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

>  On Wed, 2025-06-11 at 20:16 -0700, Stefan Reinauer wrote:
>  > > Sorry, Adrian, but you can't have it both ways. Either you support small
>  > > systems or you don't. Debian's documentation says of m68k:
>  > >
>  > >     This architecture covers Amigas and ATARIs having a Motorola 680x0
>  > >     processor for x>=2; with MMU. However, the port is still active and
>  > >     available for installation even if not a part of this official stable
>  > >     release and might be reactivated for future releases.
>  > >
>  > > https://www.debian.org/doc/manuals/debian-faq/compatibility.en.html#arches
>  > >
>  > > There is no mention of fast emulators. Yet that's all you're targeting
>  > > now.
>  >
>  > Fixing pthreads would probably go a long way. That's where we lost about half of our performance.
>  
>  This may be accurate, but I'm again not sure how this is related to the discussion we're having.
>  
>  Finn accuses me that I deliberately slow down Linux on m68k when all I do is continue to maintain
>  vanilla Debian on m68k. Modern versions of Linux being slower on slow m68k machines these days is
>  unfortunate, but it's not something I can be blamed for.
>  
>  My goal is to keep Debian's m68k alive and healthy and one critical change to make to make this whole
>  effort sustainable is to switch the default alignment to 4 bytes. If we want have a smaller and faster
>  Debian distribution available, that is still something that can be worked in a separate project and if
>  users are willing to help with such an effort, I'm happy to look into it.
>  
>  However, what I don't like is that multiple people in this thread dismiss my work completely with
>  questionable arguments and unrealistic counter-proposals when they have no clue how distributions
>  are maintained and how tedious it is to spin your own distribution.
>  
>  Adrian
>  
>  --
>   .''`.  John Paul Adrian Glaubitz
>  : :' :  Debian Developer
>  `. `'   Physicist
>    `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913
>  
>

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Jason Thorpe]

It may in fact improve performance; aligned long words require fewer bus cycles.

-- thorpej
Sent from my iPhone.

> On Jun 12, 2025, at 3:18 AM, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
> 
> It's also absurd that you think that switching the alignment to 4 bytes will
> make the port considerably slower when the contrary is the case and NetBSD
> developers on this thread have explained several times that they don't have
> any issues with 4 bytes alignment. Heck, even Amiga Unix uses 4 bytes alignment.

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Christian Groessler]

On 6/12/25 10:25 AM, Administrator @ R·V·E wrote:
> Thanks for your great hard work and efforts to mantain the various and now considered exotic architectures running Debian, Adrian!

Seconded

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Eero Tamminen]

Hi,

On 11.6.2025 18.49, John Paul Adrian Glaubitz wrote:
> On Wed, 2025-06-11 at 18:32 +0300, Eero Tamminen wrote:
>> It will decrease performance if increased alignment means that something
>> that fit earlier into i/d-cache, does not fit any more.
> 
> »Control whether GCC aligns int, long, long long, float, double, and long double
>   variables on a 32-bit boundary (-malign-int) or a 16-bit boundary (-mno-align-int).
>   Aligning variables on 32-bit boundaries produces code that runs somewhat faster on
>   processors with 32-bit busses at the expense of more memory.«

The "more memory" part is the gotcha I was referring to.


>> To get some numbers on this...
>>
>> if you could provide vmlinuz & System.map files for both (otherwise
>> identical) 2-byte & 4-byte alignment kernel builds, using kernel config
>> here:
>> https://github.com/hatari/hatari/blob/main/tools/linux/kernel.config
>>
>> I could measure the perf difference for the whole kernel boot, and if
>> there are differences, profile what causes those differences.
> 
> But anyway, as I have said before, I am not going to change my mind on this
> and I'm already working on it. If you prefer maintaining a Linux port with
> 2 bytes alignment, you are free to do so. But please don't expect me to waste
> my time on it.

Unsubstantiated performance claims are no good.  I was offering help in 
substantiating them.


If perf improves, that's validation for the performance argument. If 
performance impact is insignificant, that's proof against claims of 
4-byte alignment decreasing performance.

(Linux kernel has general "no ABI changes, as long as ABI has users" 
policy, so verified arguments like above might help sway kernel 
maintainers to help with potential 4-byte alignment issues.)


Now, if perf actually decreases with 4-byte alignment setups, it's 
something to investigate, and hopefully / eventually to fix. Pinpointing 
causes for such things is something where I can specifically help.


Note: the above kernel config is a minimal, monolithic[1] one.  It's a 
starting point, much faster to build & boot, and makes it easier to 
pinpoint issues.

After that is done, I could measure + profile also something closer to 
latest Debian kernel config, if additional data points are needed, or 
you're just interested about alignment impact for (boot time) perf in 
specific additional drivers.

(Full m68k Debian is too heavy to boot in reasonable time on machines 
that Hatari emulates, due to missing crypto acceleration, but IMHO also 
unnecessary for kernel ABI change discussions.)


	- Eero

[1] This is due to limitations in the current Hatari profiler, it was 
intended for profiling ROM code and (CPU+DSP) programs on OSes which do 
not support shared libs / modules.

(It's been used e.g. to optimize upstream ScummVM, so that subset of its 
game engines work OK even on 32Mhz 030: 
https://scummvm.org/downloads/#release)

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Finn Thain]

On Thu, 12 Jun 2025, Eero Tamminen wrote:

> It's been used e.g. to optimize upstream ScummVM, so that subset of its 
> game engines work OK even on 32Mhz 030

And therein lies the rub -- to identify those workloads which should be 
measured and to afford each one a suitable weight in your decision making. 
That's why this was always political. You can argue (with the benefit of 
hindsight) that Andrea Schwab's solution always had technical 
deficiencies. I would argue that it is a huge success regardless.
Thanks, Andreas!

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Eero Tamminen]

Hi,

On 13.6.2025 4.36, Finn Thain wrote:
> And therein lies the rub -- to identify those workloads which should be
> measured and to afford each one a suitable weight in your decision making.

It's not just workload affecting the results; compiler version, 
optimization options [1], workload & kernel config options and sometimes 
even unrelated code changes [2], can affect how given instruction 
sequence settles into cache.


 > That's why this was always political.

I'd rather keep things technical and fact-based.

Whatever testing is done, the one wider conclusion that *can* be drawn 
from it, is that if there's a noticeable performance difference, such 
differences are possible also in other workloads.

(Very large difference could indicate also functional issues, e.g. bug 
in given compiler build code generation.  That's why it's important to 
have good tooling for pinpointing what exactly is causing the difference.)


	- Eero

[1] One example is -Os vs. -O2 having 2x perf impact on Geert's 
experimental Atari drm fb code.  That would completely hide any impact 
from alignment.

[2] with more complex cache hierarchies than on m68k, adding or removing 
code elsewhere can impact cache line alignment on other parts of the 
resulting binary.  Not a concern for m68k though.

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Fri, 2025-06-13 at 13:56 +0300, Eero Tamminen wrote:
> On 13.6.2025 4.36, Finn Thain wrote:
> > And therein lies the rub -- to identify those workloads which should be
> > measured and to afford each one a suitable weight in your decision making.
> 
> It's not just workload affecting the results; compiler version, 
> optimization options [1], workload & kernel config options and sometimes 
> even unrelated code changes [2], can affect how given instruction 
> sequence settles into cache.
> 
> 
>  > That's why this was always political.
> 
> I'd rather keep things technical and fact-based.
> 
> Whatever testing is done, the one wider conclusion that *can* be drawn 
> from it, is that if there's a noticeable performance difference, such 
> differences are possible also in other workloads.
> 
> (Very large difference could indicate also functional issues, e.g. bug 
> in given compiler build code generation.  That's why it's important to 
> have good tooling for pinpointing what exactly is causing the difference.)

Even if that was the case - which it certainly isn't - code that is slower and
working is better than code that does not work at all.

Both you and Finn still seem to miss the point that the current 2 bytes alignment
path is a dead end and neither you nor Finn have made any substantial contributions
to keep this path alive.

If you want to keep this path, roll back your sleeves and get to work.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Thu, 2025-06-12 at 18:19 +1000, Finn Thain wrote:
> On Thu, 12 Jun 2025, John Paul Adrian Glaubitz wrote:
> 
> > On Wed, 2025-06-11 at 20:16 -0700, Stefan Reinauer wrote:
> > > 
> > > Fixing pthreads would probably go a long way. That's where we lost 
> > > about half of our performance.
> > 
> > This may be accurate, but I'm again not sure how this is related to the 
> > discussion we're having.
> > 
> 
> It's related because such changes could impact all of the C libraries and 
> compiler toolchains that you wish to port. So it's an example of a burden 
> created by package archive growth. 
> https://lists.debian.org/debian-68k/2025/06/msg00048.html

m68k with 4 bytes alignment works fine on NetBSD.

> It's also related because such an enhancement may involve an ABI break. 
> That's why I mentioned threading a week ago. 
> https://lists.debian.org/debian-68k/2025/06/msg00018.html

Which I don't care about because the current ABI is broken.

> > Finn accuses me that I deliberately slow down Linux on m68k when all I 
> > do is continue to maintain vanilla Debian on m68k.
> 
> Citation needed. What I have said is, Debian is bloated (in part) because 
> of its dependency graph e.g. the cmake dep on Qt, which you defended. 
> https://lists.debian.org/debian-68k/2025/05/msg00038.html

I'm not defending that system. I'm saying that I am not going to roll a custom
distribution of Debian because a few people on this list refuse to accept the
fact that the Linux/m68k ABI is broken and violates the official AT&T spec turning
the maintenance of this port more and more into a burden.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Thu, 2025-06-12 at 08:25 +0000, Administrator @ R·V·E wrote:
> Thanks for your great hard work and efforts to mantain the various and now
> considered exotic architectures running Debian, Adrian!

Thanks, and you're welcome. Unfortunately, some people like Finn and Eero don't
appreciate these efforts and seem to think that this all comes at zero costs.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Thu, 2025-06-12 at 17:54 +0300, Eero Tamminen wrote:
> Unsubstantiated performance claims are no good.  I was offering help in 
> substantiating them.

You're not offering help. You, like Finn as well, are trying to block fixing
a long-standing problem of Linux/m68k without offering any sustainable alternatives
to fix this problem.

> If perf improves, that's validation for the performance argument. If 
> performance impact is insignificant, that's proof against claims of 
> 4-byte alignment decreasing performance.

Performance was never the main argument. The main argument was unbreaking
the port. You are moving goal posts which is an indicator that you're not
interested in leading a fair and unbiased discussion.

> (Linux kernel has general "no ABI changes, as long as ABI has users" 
> policy, so verified arguments like above might help sway kernel 
> maintainers to help with potential 4-byte alignment issues.)

NetBSD has been building several thousand packages on m68k with 4 bytes alignment
without any problems. Why anyone would think that 4 bytes alignment poses a problem
is beyond me.

> Now, if perf actually decreases with 4-byte alignment setups, it's 
> something to investigate, and hopefully / eventually to fix. Pinpointing 
> causes for such things is something where I can specifically help.

I'm not sure how a package that doesn't build at all runs faster than one
that builds. You are arguing like this is about performance, it isn't.

It's about unbreaking the port since more and more packages assume 4 bytes
alignment. Do you think that something that is not working at all should
be preferred over something that is working with degraded performance?

> (Full m68k Debian is too heavy to boot in reasonable time on machines 
> that Hatari emulates, due to missing crypto acceleration, but IMHO also 
> unnecessary for kernel ABI change discussions.)

Last time I booted Debian/m68k on my Amiga 68060 it booted fine. It took
a few minutes but that's not surprising given the machine has only 50 MHz.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Geert Uytterhoeven]

Hi Adrian,

On Sat, 7 Jun 2025 at 11:44, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On Fri, 2025-06-06 at 20:20 +1000, Finn Thain wrote:
> > Whereas, the ability to use old binaries is proof that we care about rule
> > #1 don't break userspace.
>
> Who is "we"? The official(!) ABI says that pointers are supposed to be aligned
> with 4 bytes, not 2 bytes. It's the current implementation that violates the
> ABI, not what I want to achieve which is make Linux/m68k adhere to the official
> specification.

"The official(!) ABI"...

Official according to what and to who?
There are de jure and de facto standards.

There's a lot of discussion and talking next to each other about
"the ABI", and which ABI applies to what...

The SVR4 ABI applies to systems claiming compatibility with SVR4, which
was (AFAIK) never a goal for Linux. Before that, there were other ABIs
used by various UNIX systems (BSD, SYSV, ...) and non-Unix systems
(AmigaOS, Atari TOS, MacOS, ...).

From its inception, Linux/m68k used an ABI compatible with SunOS,
which dates back to the MC68000, and was probably the most popular
UNIX OS running on m68k at that time.  Several other UNIX vendors
followed a similar path, starting from the MC68000.  E.g. the HP-UX
Portability Guide[1] states that HP-UX on HP9000/300 (based on SVR2
at that time, apparently) uses an alignment of 2 bytes, too.

SVR4 was an attempt to consolidate the various flavors of UNIX at
that time (with BSD and SYSV being the two largest flavours), and
"rebooted" the ABI.  Binary-compatibility with older versions was
ignored, as the UNIX landscape was wildly differing anyway, and
people cared mostly about source-compatibility.

Linux has a strong history of not breaking the ABI between kernel and
user space, so changing that ABI is a no-go.  What you do in the layers
above (in the kernel), or above (in userspace) is something different...

[1] http://www.bitsavers.org/pdf/hp/9000_hpux/7.x/98794-90047_HP-UX_Portability_Guide_Sep89.pdf

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

Hello Geert,

On Fri, 2025-06-13 at 13:55 +0200, Geert Uytterhoeven wrote:
> "The official(!) ABI"...
> 
> Official according to what and to who?
> There are de jure and de facto standards.
> 
> There's a lot of discussion and talking next to each other about
> "the ABI", and which ABI applies to what...
> 
> The SVR4 ABI applies to systems claiming compatibility with SVR4, which
> was (AFAIK) never a goal for Linux. Before that, there were other ABIs
> used by various UNIX systems (BSD, SYSV, ...) and non-Unix systems
> (AmigaOS, Atari TOS, MacOS, ...).
> 
> From its inception, Linux/m68k used an ABI compatible with SunOS,
> which dates back to the MC68000, and was probably the most popular
> UNIX OS running on m68k at that time.  Several other UNIX vendors
> followed a similar path, starting from the MC68000.  E.g. the HP-UX
> Portability Guide[1] states that HP-UX on HP9000/300 (based on SVR2
> at that time, apparently) uses an alignment of 2 bytes, too.
> 
> SVR4 was an attempt to consolidate the various flavors of UNIX at
> that time (with BSD and SYSV being the two largest flavours), and
> "rebooted" the ABI.  Binary-compatibility with older versions was
> ignored, as the UNIX landscape was wildly differing anyway, and
> people cared mostly about source-compatibility.
> 
> Linux has a strong history of not breaking the ABI between kernel and
> user space, so changing that ABI is a no-go.  What you do in the layers
> above (in the kernel), or above (in userspace) is something different...
> 
> [1] http://www.bitsavers.org/pdf/hp/9000_hpux/7.x/98794-90047_HP-UX_Portability_Guide_Sep89.pdf

Okay and how does this now fix the problems we're having on Linux/m68k?

https://wiki.debian.org/M68k/Alignment

We're compatible to "fails to build from source" now. I'm not sure how this
is any helpful.

I'm not sure why several people are contributing to this discussion with
the argument that this change would break the "Linux ABI" when the Linux
ABI is currently broken and doesn't even allow for Python to be built without
further modifications.

What is your suggested alternative? Do you expect me to patch broken packages
into all eternity? If keeping 2 bytes alignment ABI is so important to so many
people, I would expect proponents to come up with solutions.

So far, I haven't seen any. Just arguments why my approach is wrong.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Geert Uytterhoeven]

Hi Adrian,

On Fri, 13 Jun 2025 at 14:00, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On Fri, 2025-06-13 at 13:55 +0200, Geert Uytterhoeven wrote:
> > From its inception, Linux/m68k used an ABI compatible with SunOS,
> > which dates back to the MC68000, and was probably the most popular
> > UNIX OS running on m68k at that time.  Several other UNIX vendors
> > followed a similar path, starting from the MC68000.  E.g. the HP-UX
> > Portability Guide[1] states that HP-UX on HP9000/300 (based on SVR2
> > at that time, apparently) uses an alignment of 2 bytes, too.

> > Linux has a strong history of not breaking the ABI between kernel and
> > user space, so changing that ABI is a no-go.

> Okay and how does this now fix the problems we're having on Linux/m68k?
>
> https://wiki.debian.org/M68k/Alignment
>
> We're compatible to "fails to build from source" now. I'm not sure how this
> is any helpful.
>
> I'm not sure why several people are contributing to this discussion with
> the argument that this change would break the "Linux ABI" when the Linux
> ABI is currently broken and doesn't even allow for Python to be built without
> further modifications.

You mean Python is broken, as it makes assumptions that are not
guaranteed by the C standard (oops, which one? ;-) ? ;-)

Lots of older packages used to build fine on much more obscure systems
than Linux/m68k.  Unfortunately people stopped caring for anything
not 64-bit little endian.  Yes, I know saying that doesn't help...

> What is your suggested alternative? Do you expect me to patch broken packages
> into all eternity? If keeping 2 bytes alignment ABI is so important to so many
> people, I would expect proponents to come up with solutions.
>
> So far, I haven't seen any. Just arguments why my approach is wrong.

You are completely ignoring the last sentence I wrote...

> >  What you do in the layers
> > above (in the kernel), or above (in userspace) is something different...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Fri, 2025-06-13 at 14:09 +0200, Geert Uytterhoeven wrote:
> You mean Python is broken, as it makes assumptions that are not
> guaranteed by the C standard (oops, which one? ;-) ? ;-)

Not just Python but a lot of packages which I have listed here:

https://wiki.debian.org/M68k/Alignment

This does not even cover the transitive dependencies.

> Lots of older packages used to build fine on much more obscure systems
> than Linux/m68k.  Unfortunately people stopped caring for anything
> not 64-bit little endian.  Yes, I know saying that doesn't help...

Yes, *used* to work. But that's past tense.

> > What is your suggested alternative? Do you expect me to patch broken packages
> > into all eternity? If keeping 2 bytes alignment ABI is so important to so many
> > people, I would expect proponents to come up with solutions.
> > 
> > So far, I haven't seen any. Just arguments why my approach is wrong.
> 
> You are completely ignoring the last sentence I wrote...

Because I am *extremely* tired of people heckling this discussion without *helping* me.

I have had multiple moments where I thought to just throw this all into the bin, turn
off the buildds and deleting the m68k archives because it's really hurting my sanity.

I am fully aware that this change breaks the existing ABI. However, as I explained before,
changing the default alignment to 4 bytes is the *only* way to keep this port alive in the
long term and anyone who is interested in this port should either agree with me or present
a suitable alternative to me. The latter still has not happened yet.

Continuing discussion about possible performance hits like Eero or moving goal posts like
Finn is not going to address this problem. Rather, it's just making me feel worse and questioning
my life decisions.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Geert Uytterhoeven]

Hi Adrian,

On Fri, 13 Jun 2025 at 14:23, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On Fri, 2025-06-13 at 14:09 +0200, Geert Uytterhoeven wrote:
> > You are completely ignoring the last sentence I wrote...
>
> Because I am *extremely* tired of people heckling this discussion without *helping* me.
>
> I have had multiple moments where I thought to just throw this all into the bin, turn
> off the buildds and deleting the m68k archives because it's really hurting my sanity.
>
> I am fully aware that this change breaks the existing ABI. However, as I explained before,
> changing the default alignment to 4 bytes is the *only* way to keep this port alive in the
> long term and anyone who is interested in this port should either agree with me or present
> a suitable alternative to me. The latter still has not happened yet.

> > > >  What you do in the layers
> > > > above (in the kernel), or above (in userspace) is something different...

So you change the default alignment, bump all so-versions in userspace,
but keep the kernel-userspace ABI the same by adding explicit alignment
tags where needed? Old binaries keep on working, new binaries join
the ecosystem of anything that still builds on 32-bit big-endian ;-)

Win-win?

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Fri, 2025-06-13 at 14:30 +0200, Geert Uytterhoeven wrote:
> So you change the default alignment, bump all so-versions in userspace,
> but keep the kernel-userspace ABI the same by adding explicit alignment
> tags where needed? Old binaries keep on working, new binaries join
> the ecosystem of anything that still builds on 32-bit big-endian ;-)

I think you're still missing the part that I'm not maintaining my own Linux
distribution meaning that I cannot bump SO versions or making any substantial
changes to the distributions.

And I'm not sure why being able to run old binaries on a retro-computing architecture
is is so important for some people that they think it justifies making my life
miserable.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Fri, 2025-06-13 at 14:51 +0200, John Paul Adrian Glaubitz wrote:
> On Fri, 2025-06-13 at 14:30 +0200, Geert Uytterhoeven wrote:
> > So you change the default alignment, bump all so-versions in userspace,
> > but keep the kernel-userspace ABI the same by adding explicit alignment
> > tags where needed? Old binaries keep on working, new binaries join
> > the ecosystem of anything that still builds on 32-bit big-endian ;-)
> 
> I think you're still missing the part that I'm not maintaining my own Linux
> distribution meaning that I cannot bump SO versions or making any substantial
> changes to the distributions.

To make this perfectly clear: The whole point about making this change is to *not*
having to roll my own Linux distribution for Linux/m68k. I'm building vanilla Debian
on m68k which means that I *don't* want to make any changes to the distribution as
I simply do not have any control over this.

Do you expect that I can go to the glibc project and ask them to bump the ABI version
from 6 to 7 because some people think it's extremely important to be able to run a 1993
Linux binary an Amiga running a Debian unstable snapshot from 2025.

I really don't understand why anyone can make such a suggestion and think "Yeah, that's
completely reasonable to do. Let's completely change half of the Debian distribution so
we don't break the ABI on Debian/m68k for binaries from 1993."

Flipping the switch to 4 bytes alignment will allow me to build vanilla Debian without
having to patch dozens of package to make them build on m68k. I want to have less work,
not more.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[ALeX Kazik]

Hi,

I'm only reading here because I installed debian on my Amiga a long
time ago, and just for fun.

And I think that the people who keep this running should be able to
decide the future.
But that is only my opinion.

Alex.

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Klos]

Hi,

> You're not offering help. You, like Finn as well, are trying to block fixing
> a long-standing problem of Linux/m68k without offering any sustainable alternatives
> to fix this problem.

I didn't see anywhere that Eero was blocking or hinting at blocking. I 
only saw Eero offering to collect data, which I think is a good idea.

It might not be directly relevant to the issue at hand, but we shouldn't 
say no to more information that might inform these changes, either for 
better or for worse.

John

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

Hi John,

On Fri, 2025-06-13 at 13:21 +0000, John Klos wrote:
> > You're not offering help. You, like Finn as well, are trying to block fixing
> > a long-standing problem of Linux/m68k without offering any sustainable alternatives
> > to fix this problem.
> 
> I didn't see anywhere that Eero was blocking or hinting at blocking. I 
> only saw Eero offering to collect data, which I think is a good idea.
> 
> It might not be directly relevant to the issue at hand, but we shouldn't 
> say no to more information that might inform these changes, either for 
> better or for worse.

I'm not saying that any criticism is wrong per se. I just want anyone in this
thread to understand that suggestions like bumping all SO versions or rolling
your own version of Debian is not helping the cause and Eero has made such
suggestions.

Some people seem to have the impression that I maintain the source code over all
the packages being built on Debian/m68k. I don't. I am building what's available
in Debian unstable and I want to be able to build as many of these packages without
having to patch them.

While patching packages is possible in general, most upstream and Debian maintainers
don't really want to deal with patches that enable the build on 2 bytes alignment
meaning that I have to keep building the affected packages in question manually
forever which I really don't want to.

Switching the default alignment will fix a plethora of broken packages and while it
may come with some regressions here and there, I am very confident it's the right
way to go.

The Gentoo developers are pursuing this path as well meaning that there won't be
any distributions with 2 bytes alignment left.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Eero Tamminen]

Hi,

On 13.6.2025 15.51, John Paul Adrian Glaubitz wrote:
> On Fri, 2025-06-13 at 14:30 +0200, Geert Uytterhoeven wrote:
>> So you change the default alignment, bump all so-versions in userspace,
>> but keep the kernel-userspace ABI the same by adding explicit alignment
>> tags where needed? Old binaries keep on working, new binaries join
>> the ecosystem of anything that still builds on 32-bit big-endian ;-)
> 
> I think you're still missing the part that I'm not maintaining my own Linux
> distribution meaning that I cannot bump SO versions or making any substantial
> changes to the distributions.>
> And I'm not sure why being able to run old binaries on a retro-computing architecture
> is is so important for some people that they think it justifies making my life
> miserable.

Wouldn't next upgrade completely break user's Debian system so it needs 
complete re-install?

If true, would separate m68k arch for 4-byte alignment be out of 
question, similarly how there have been different ARM arch variants?


	- Eero

PS. I was peripherally involved in the ARM VFP thing, in a Debian 
derivative that switched to use VFP before Debian did. So I know a bit 
how big thing such transition is, even with the Debian cross-compiling & 
boot-strapping support being much better now...

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Fri, 2025-06-13 at 17:15 +0300, Eero Tamminen wrote:
> Wouldn't next upgrade completely break user's Debian system so it needs 
> complete re-install?

You would need to extract the glibc package manually from my tests. After that,
upgrading the system should be possible.

> If true, would separate m68k arch for 4-byte alignment be out of 
> question, similarly how there have been different ARM arch variants?

Creating a separate arch would mean patching various parts of Debian which
again would involve a lot of work which I don't think is worth the effort.

I don't think the userbase is large enough to warrant all that work.

> PS. I was peripherally involved in the ARM VFP thing, in a Debian 
> derivative that switched to use VFP before Debian did. So I know a bit 
> how big thing such transition is, even with the Debian cross-compiling & 
> boot-strapping support being much better now...

That's why I want to make a hard cut and not invest months of work when the
userbase consists of just a few people.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Laurent Vivier]

Hi Adrian,

Le 13/06/2025 à 16:53, John Paul Adrian Glaubitz a écrit :

> On Fri, 2025-06-13 at 17:15 +0300, Eero Tamminen wrote:
>> Wouldn't next upgrade completely break user's Debian system so it needs
>> complete re-install?
> 
> You would need to extract the glibc package manually from my tests. After that,
> upgrading the system should be possible.
> 
>> If true, would separate m68k arch for 4-byte alignment be out of
>> question, similarly how there have been different ARM arch variants?
> 
> Creating a separate arch would mean patching various parts of Debian which
> again would involve a lot of work which I don't think is worth the effort.
> 
> I don't think the userbase is large enough to warrant all that work.
> 
>> PS. I was peripherally involved in the ARM VFP thing, in a Debian
>> derivative that switched to use VFP before Debian did. So I know a bit
>> how big thing such transition is, even with the Debian cross-compiling &
>> boot-strapping support being much better now...
> 
> That's why I want to make a hard cut and not invest months of work when the
> userbase consists of just a few people.
> 

A stupid question: is this possible to remove from debian the packets 
that are broken?
(I'm sorry if you already answered to this question).

Because I'm afraid that changing the ABI could cause more problems than 
it solves.

Thanks,
Laurent

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[David Brownlee]

On Fri, 13 Jun 2025 at 12:55, Geert Uytterhoeven <geert@linux-m68k.org> wrote:
>
> Hi Adrian,
>
> On Sat, 7 Jun 2025 at 11:44, John Paul Adrian Glaubitz
> <glaubitz@physik.fu-berlin.de> wrote:
> > On Fri, 2025-06-06 at 20:20 +1000, Finn Thain wrote:
> > > Whereas, the ability to use old binaries is proof that we care about rule
> > > #1 don't break userspace.
> >
> > Who is "we"? The official(!) ABI says that pointers are supposed to be aligned
> > with 4 bytes, not 2 bytes. It's the current implementation that violates the
> > ABI, not what I want to achieve which is make Linux/m68k adhere to the official
> > specification.
>
> "The official(!) ABI"...
>
> Official according to what and to who?
> There are de jure and de facto standards.
>
> There's a lot of discussion and talking next to each other about
> "the ABI", and which ABI applies to what...
>
> The SVR4 ABI applies to systems claiming compatibility with SVR4, which
> was (AFAIK) never a goal for Linux. Before that, there were other ABIs
> used by various UNIX systems (BSD, SYSV, ...) and non-Unix systems
> (AmigaOS, Atari TOS, MacOS, ...).
>
> From its inception, Linux/m68k used an ABI compatible with SunOS,
> which dates back to the MC68000, and was probably the most popular
> UNIX OS running on m68k at that time.  Several other UNIX vendors
> followed a similar path, starting from the MC68000.  E.g. the HP-UX
> Portability Guide[1] states that HP-UX on HP9000/300 (based on SVR2
> at that time, apparently) uses an alignment of 2 bytes, too.
>
> SVR4 was an attempt to consolidate the various flavors of UNIX at
> that time (with BSD and SYSV being the two largest flavours), and
> "rebooted" the ABI.  Binary-compatibility with older versions was
> ignored, as the UNIX landscape was wildly differing anyway, and
> people cared mostly about source-compatibility.
>
> Linux has a strong history of not breaking the ABI between kernel and
> user space, so changing that ABI is a no-go.  What you do in the layers
> above (in the kernel), or above (in userspace) is something different...

I think it is generally accepted that this would be a new ABI - a
little similar to MIPS o32 vs n32, but with the twist that all CPUs
support the new ABI and the goal would be for the old ABI to be
entirely replaced.

If that is the case, the real issue would be how to manage the
coexistence with the existing 2 byte alignment ABI port.

One option would be to give it a new port name. Sensible if this was a
more mainstream port, but given the limited Debian engineering
resources (waves at glaubitz@), and desire to replace the existing ABI
entirely, I think the effort (and breakage in packages not knowing
about the new cpu name) is probably not warranted.

Given that, I think there are a number of options (of increasing effort):

1) Just to build the new ABI port with the same name, and accept that
attempts to run binaries between the two systems will fail without any
specific indication

2) Add an ELF note on new ABI binaries (similar to NetBSD/sparc64),
and have the new system fail to run old binaries with a helpful
message

3) Also add a compat layer to the new system to be able to call into a
separate set of abi libs and to versioned system calls (rewriting the
alignment data as needed), similar to NetBSD with it's a.out (2 byte
alignment) to ELF transition (4 byte alignment). That kernel ABI
versioning is likely to be a.... non trivial amount of effort, but
would allow old binaries to run transparently

These stack, so 2) only makes sense if 1) is working, and 3) if 2) is working.

My understanding is glaubitz@ is working on 1). Assuming that goes
well and unlocks a bunch of additional packages for m68k as expected,
then I think it is worth discussing whether 2) or 3) are needed and
who would work on them.

I personally think 2) is definitely worth considering, but as I'm not
volunteering to do the work, my opinion can be taken with a pinch of
salt :-p

An elephant in the room is "what if the performance hit of 4 byte
alignment is significant".

In that case some people may want to continue the 2 byte alignment
port (though I think it's safe to say at this point that unless it
reduces the performance to NS32008 leves, glaubitz@ plans to complete
and maintain the 4 byte alignment port).

In that case adding 2) plus the code to detect and reject new ABI
binaries on old systems becomes if anything more interesting, and....
I'm sure we can look forward to more animated discussions on these
lists...

David

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Eero Tamminen]

Hi,

On 13.6.2025 17.53, John Paul Adrian Glaubitz wrote:
> On Fri, 2025-06-13 at 17:15 +0300, Eero Tamminen wrote:
>> Wouldn't next upgrade completely break user's Debian system so it needs
>> complete re-install?
> 
> You would need to extract the glibc package manually from my tests. After that,
> upgrading the system should be possible.

I think quite a bit more binaries than just Glibc are needed for Debian 
upgrade tooling to work, but OK.

As to other potential issues...

I assume there are no m68k port packages with closed source executable 
code (FW) [1], like the other architectures (esp. x86) have & need, and 
that any code intended to work also on non-m68k platform, should be fine 
with 4-byte alignment.

But what about m68k specific C/C++ and assembly code that may hard-code 
2-byte alignment assumptions; is there any tooling to detect (potential) 
alignment issues in those?

Or is the plan just to rely on packages' self-tests to reveal issues, 
and then track them down from there?


[1] Are sources for "bootstra.tos" & "amiboot" anywhere, in case they 
need updates:
https://wiki.debian.org/M68k/Installing
https://people.debian.org/~wouter/d-i/images/20130502-06:51/tools/atari/
https://people.debian.org/~wouter/d-i/images/20130502-06:51/tools/amiga/
?


>> If true, would separate m68k arch for 4-byte alignment be out of
>> question, similarly how there have been different ARM arch variants?
> 
> Creating a separate arch would mean patching various parts of Debian which
> again would involve a lot of work which I don't think is worth the effort.
...
> That's why I want to make a hard cut and not invest months of work when the
> userbase consists of just a few people.

Ok, fair enough.

Are there any statistics on how many Debian packages do (still) include 
m68k assembly?

If that number is limited enough, it could help in getting other people 
to review the assembly code for potential alignment issues...

Glibc is likely on top of that list (but also most likely to be 
alignment neutral):
	glibc$ find -name '*.S' | grep m68k | wc -l
	25

As *BSD already uses 4-byte alignment, I assume that for packages 
containing m68k assembly that do support / work also on *BSD in addition 
to Linux, m68k asm code used on both should work fine, and one needs to 
review only m68k asm that differs on Linux.

(I'm thinking of acceleration code, not syscall bindings, those I guess 
to differ anyway between the OSes.)


	- Eero

Re: Debian boot/login time

[Eero Tamminen]

Hi,

(Updated subject.)

On 13.6.2025 14.22, John Paul Adrian Glaubitz wrote:
> On Thu, 2025-06-12 at 17:54 +0300, Eero Tamminen wrote:
>> (Full m68k Debian is too heavy to boot in reasonable time on machines
>> that Hatari emulates, due to missing crypto acceleration, but IMHO also
>> unnecessary for kernel ABI change discussions.)

Note that above is about Debian defaults.  What one gets before being 
able to locate, disable and configure every option and service that 
makes things crawl (and build own kernel more optimal for that setup).


> Last time I booted Debian/m68k on my Amiga 68060 it booted fine. It took
> a few minutes but that's not surprising given the machine has only 50 MHz.

It's few years since I tried it, but I was testing on (emulated) 030 @ 
32Mhz [1] which is quite a bit slower than your setup, and I included 
logging into console to "booting Debian".

When Debian changed encryption default from MD5 to SHA512, login time 
exploded. If I don't completely misremember, it took something like 20 
min.  Switching PAM back to MD5 helped a lot with login.

Debian has switched to "yescrypt" since then, which I assume to be even 
slower default. :-)

=> It's hard for me to image somebody even trying to use something like 
KDE, Gnome or Libreoffice on m68k HW, even fast FPGA ones.


	- Eero

[1] Hatari can emulate up to 060 @ 32Mhz, but 060 emulation did not work 
with Linux when I did that testing.  It does now, but unlike with 030, 
only if one disables d/i-cache emulation...

(My Google-Foo may be lacking, but at least I did not find any guide / 
wiki helping to optimize Debian for such slow setup, so I gave up, as I 
had other issues to investigate / solve.)

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Finn Thain]

On Fri, 13 Jun 2025, John Paul Adrian Glaubitz wrote:

> 
> Both you and Finn still seem to miss the point that the current 2 bytes 
> alignment path is a dead end and neither you nor Finn have made any 
> substantial contributions to keep this path alive.
> 
> If you want to keep this path, roll back your sleeves and get to work.
> 

I made the offer to help last year and then followed through. And you know 
it, because you commented on the bug report [1]. Yet you subsequently 
claimed, falsely and repeatedly, that I've done nothing.

Of course, you have to do this in order to try to discredit. Also, your 
stance obliges you to ignore the work of others, because that work 
demonstrates that the bugs in question are not really related to alignment 
or ABI in the first place. They are straight-forward bad code, like 
pointer abuse in Python [1] or over-strict assertions in Linux [2].

Apparently you don't have time to improve all the upstream codebases that 
you want to port -- though you do have time for sniping at that effort [1] 
[2].

Want interests you is a zero-effort port, with no guarantee of ABI 
stability and no history. You want 100% package archive coverage, with no 
regard for the applicability of those packages to Motorola or NXP 
hardware.

So I fail to see how your plans would serve Debian or the wider Linux/m68k 
community. But perhaps that will become clear once you "roll back your 
sleeves" and send patches.

[1]
https://github.com/python/cpython/issues/127545
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1105110

[2]
https://lore.kernel.org/linux-m68k/CAMuHMdWvmwvtA3F3vuYxiDf94Mn2o7TTQ9G-erv-ZfNVjMZrRg@mail.gmail.com/

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Finn Thain]

On Fri, 13 Jun 2025, John Paul Adrian Glaubitz wrote:

> On Thu, 2025-06-12 at 18:19 +1000, Finn Thain wrote:
> > On Thu, 12 Jun 2025, John Paul Adrian Glaubitz wrote:
> > 
> > > On Wed, 2025-06-11 at 20:16 -0700, Stefan Reinauer wrote:
> > > > 
> > > > Fixing pthreads would probably go a long way. That's where we lost 
> > > > about half of our performance.
> > > 
> > > This may be accurate, but I'm again not sure how this is related to 
> > > the discussion we're having.
> > > 
> > 
> > It's related because such changes could impact all of the C libraries 
> > and compiler toolchains that you wish to port. So it's an example of a 
> > burden created by package archive growth. 
> > https://lists.debian.org/debian-68k/2025/06/msg00048.html
> 
> m68k with 4 bytes alignment works fine on NetBSD.
> 

Please read the messages you reply to. The topic was a regression.

> > It's also related because such an enhancement may involve an ABI break. 
> > That's why I mentioned threading a week ago. 
> > https://lists.debian.org/debian-68k/2025/06/msg00018.html
> 
> Which I don't care about because the current ABI is broken.
> 

You should care! If you are going to get a new ABI, either you are going 
to do that work yourself or you'll have to collaborate with others who 
want certain characteristics from a new ABI.

And here again, it appears that you never read the message you're replying 
to. (And here I am, making the spam problem worse by replying to it...)

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Finn Thain]

On Fri, 13 Jun 2025, John Paul Adrian Glaubitz wrote:

> 
> Performance was never the main argument. The main argument was 
> unbreaking the port. You are moving goal posts which is an indicator 
> that you're not interested in leading a fair and unbiased discussion.
> 

Linux/m68k is not broken, Gentoo/m68k is not broken and buildroot is not 
broken. They don't require that I build LLVM. They don't require that I 
build _multiple_ implementations of Rust and Go. They don't require that I 
build Qt in order to build cmake. So I suggest you fix your package 
archive and package manager.

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Finn Thain]

On Fri, 13 Jun 2025, John Paul Adrian Glaubitz wrote:

> 
> Do you expect me to patch broken packages into all eternity?

Some volunteers go looking for bugs to fix and problems to solve, but 
no-one expects them to do it. Others are getting paid to do it. Most 
people simply don't have time for that -- nothing to be ashamed of.

FWIW, I'm not getting paid. Nor am I trying to get hired in the future.

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Finn Thain]

On Fri, 13 Jun 2025, John Paul Adrian Glaubitz wrote:

> 
> I really don't understand why anyone can make such a suggestion and 
> think "Yeah, that's completely reasonable to do. Let's completely change 
> half of the Debian distribution ..."

But you should completely change half of the Debian distribution (package 
archive and package manager) when doing so serves all users of small 
systems.

That's quite sensible because all systems will become small systems, if 
history is any guide at all.

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Finn Thain]

On Fri, 13 Jun 2025, ALeX Kazik wrote:

> And I think that the people who keep this running should be able to 
> decide the future. But that is only my opinion.

You're quite right, and that's how the process has always worked. The 
discussion is mostly spam, given that the question was always going to be 
decided by those capable of writing viable patches.

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Fri, 2025-06-13 at 17:24 +0200, Laurent Vivier wrote:
> A stupid question: is this possible to remove from debian the packets 
> that are broken?
> (I'm sorry if you already answered to this question).

Sure, we can remove Python on m68k. But whether it will still be useful
after that remains a different question. I would argue we should rather
totally drop the port then because Linux without Python doesn't really
work these days.

> Because I'm afraid that changing the ABI could cause more problems than 
> it solves.

For what exact reason? NetBSD/m68k runs with 4 bytes alignment.
Why shouldn't this work for Linux?

And I have bootstrapped Debian/m68k using rebootstrap with 4 bytes alignment
without any problems. If you think there are problems with 4 bytes alignment,
I would like to see them reported.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Fri, 2025-06-13 at 22:29 +0300, Eero Tamminen wrote:
> I think quite a bit more binaries than just Glibc are needed for Debian 
> upgrade tooling to work, but OK.

I have already performed tests with 4 bytes alignment, same applies to
the Gentoo developers.

I assume you have done your tests as well so far? What are your results?

> As to other potential issues...
> 
> I assume there are no m68k port packages with closed source executable 
> code (FW) [1], like the other architectures (esp. x86) have & need, and 
> that any code intended to work also on non-m68k platform, should be fine 
> with 4-byte alignment.
> 
> But what about m68k specific C/C++ and assembly code that may hard-code 
> 2-byte alignment assumptions; is there any tooling to detect (potential) 
> alignment issues in those?

Here's a list of almost 6000 software packages that build fine on m68k with
4 bytes alignment:

https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/m68k/9.0_2023Q4/All/

> Or is the plan just to rely on packages' self-tests to reveal issues, 
> and then track them down from there?

I will fix these problems as they occur meaning I will just do what I did
before with the 2 bytes alignment failures.

> [1] Are sources for "bootstra.tos" & "amiboot" anywhere, in case they 
> need updates:
> https://wiki.debian.org/M68k/Installing
> https://people.debian.org/~wouter/d-i/images/20130502-06:51/tools/atari/
> https://people.debian.org/~wouter/d-i/images/20130502-06:51/tools/amiga/
> ?

I don't think these would need to be updated but this can be tested.

> > 
> Are there any statistics on how many Debian packages do (still) include 
> m68k assembly?

I don't expect anything outside glibc, the kernel and GCC to use assembly
on m68k. And even if, the fact that the NetBSD people don't have to patch
everything to work with 4 bytes shows that there is nothing to worry about.

I am planning to rebuild and test the whole archive first anyway before
actually making the switch. I'm also monitoring what the Gentoo folks are
doing.

> If that number is limited enough, it could help in getting other people 
> to review the assembly code for potential alignment issues...
> 
> Glibc is likely on top of that list (but also most likely to be 
> alignment neutral):
> 	glibc$ find -name '*.S' | grep m68k | wc -l
> 	25
> 
> As *BSD already uses 4-byte alignment, I assume that for packages 
> containing m68k assembly that do support / work also on *BSD in addition 
> to Linux, m68k asm code used on both should work fine, and one needs to 
> review only m68k asm that differs on Linux.

Exactly my point. It works on NetBSD, so I'm not worried about Linux.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Eero Tamminen]

Hi,

On 14.6.2025 10.51, John Paul Adrian Glaubitz wrote:
> Here's a list of almost 6000 software packages that build fine on m68k with
> 4 bytes alignment:
> 
> https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/m68k/9.0_2023Q4/All/
...
> Exactly my point. It works on NetBSD, so I'm not worried about Linux.

I don't see in above dir e.g. LLVM or Qt, which were in the Debian 
2-byte alignment problems list:
	https://wiki.debian.org/M68k/Alignment

Are those in some other place, do they have other problems besides the 
2-byte alignment, or am I just blind?

(Many other less relevant packages from that Debian list seem also to be 
missing from that NetBSD dir.)


	- Eero

PS. I really appreciate your Debian m68k maintenance effort. As my 
contributions for m68k are elsewhere (Hatari emulator, EmuTOS ROM for 
Atari&Amiga, m68k SW profiling etc), and you were not interested about 
profiling help at this stage, I naturally don't have any say on this.

But note that what Debian (and Gentoo) do, has also wider (indirect) 
impact, so it's definitely of interest also for people who do not use 
them regularly, or don't directly contribute to them, who e.g:

* do contribute to projects that Debian packages

* use only m68k cross-compiler and small subset of m68k packages

* appreciate Debian/Gentoo checking that latest toolchains & OSS SW in 
general support m68k, and bugs are being filed about that
   - those non-Debian people can then also look into / try fix those 
bugs, e.g. when they update their toolchains next...

So please bear with us!

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Klos]

> I don't see in above dir e.g. LLVM or Qt, which were in the Debian 2-byte 
> alignment problems list:
> 	 https://wiki.debian.org/M68k/Alignment

Our package lists include as much as could be built in a given quarter. 
The current quarter has, for example, llvm and clang:

https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/m68k/10.0_2025Q1/All/

> Are those in some other place, do they have other problems besides the 2-byte 
> alignment, or am I just blind?
>
> (Many other less relevant packages from that Debian list seem also to be 
> missing from that NetBSD dir.)

There are reports which include build failures that will be available once 
the quarter is over, but the primary reason packages you might expect to 
be there aren't is simply the speed of our build machines.

John

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Finn Thain]

On Sat, 14 Jun 2025, John Paul Adrian Glaubitz wrote:

> 
> Sure, we can remove Python on m68k. But whether it will still be useful 
> after that remains a different question. I would argue we should rather 
> totally drop the port then because Linux without Python doesn't really 
> work these days.
> 

https://lists.debian.org/debian-68k/2024/10/msg00042.html
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1105110

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Sat, 2025-06-14 at 11:20 +0000, John Klos wrote:
> > I don't see in above dir e.g. LLVM or Qt, which were in the Debian 2-byte 
> > alignment problems list:
> > 	 https://wiki.debian.org/M68k/Alignment
> 
> Our package lists include as much as could be built in a given quarter. 
> The current quarter has, for example, llvm and clang:
> 
> https://cdn.netbsd.org/pub/pkgsrc/packages/NetBSD/m68k/10.0_2025Q1/All/

It's great to see that all the effort that went into LLVM on m68k is materializing
on NetBSD. Thanks for sharing this <3.

> > Are those in some other place, do they have other problems besides the 2-byte 
> > alignment, or am I just blind?
> > 
> > (Many other less relevant packages from that Debian list seem also to be 
> > missing from that NetBSD dir.)
> 
> There are reports which include build failures that will be available once 
> the quarter is over, but the primary reason packages you might expect to 
> be there aren't is simply the speed of our build machines.

Please post them on the port-m68k mailing list once they become available.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Sun, 2025-06-15 at 11:42 +1000, Finn Thain wrote:
> On Sat, 14 Jun 2025, John Paul Adrian Glaubitz wrote:
> 
> > 
> > Sure, we can remove Python on m68k. But whether it will still be useful 
> > after that remains a different question. I would argue we should rather 
> > totally drop the port then because Linux without Python doesn't really 
> > work these days.
> > 
> 
> https://lists.debian.org/debian-68k/2024/10/msg00042.html
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1105110

Honest question, Finn: Why are you even participating in this discussion when
you're neither willing to acknowledge the problem nor willing to help address
it?

Do you think that you just need to bombard me with repeated statements that I
am going to change my mind over something that I have chewed over for so long?

I think everyone in this thread has now understood that you are neither willing
to help resolve these issues nor are you willing to accept my preferred solution
that Gentoo and I are already working on.

So, what's the deal with your continued engagement?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Geert Uytterhoeven]

Hi Adrian,

On Fri, 13 Jun 2025 at 15:00, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On Fri, 2025-06-13 at 14:51 +0200, John Paul Adrian Glaubitz wrote:
> > On Fri, 2025-06-13 at 14:30 +0200, Geert Uytterhoeven wrote:
> > > So you change the default alignment, bump all so-versions in userspace,
> > > but keep the kernel-userspace ABI the same by adding explicit alignment
> > > tags where needed? Old binaries keep on working, new binaries join
> > > the ecosystem of anything that still builds on 32-bit big-endian ;-)
> >
> > I think you're still missing the part that I'm not maintaining my own Linux
> > distribution meaning that I cannot bump SO versions or making any substantial
> > changes to the distributions.
>
> To make this perfectly clear: The whole point about making this change is to *not*
> having to roll my own Linux distribution for Linux/m68k. I'm building vanilla Debian
> on m68k which means that I *don't* want to make any changes to the distribution as
> I simply do not have any control over this.
>
> Do you expect that I can go to the glibc project and ask them to bump the ABI version
> from 6 to 7 because some people think it's extremely important to be able to run a 1993
> Linux binary an Amiga running a Debian unstable snapshot from 2025.

Sorry, I didn't know you have to coordinate this with the glibc project.
But you have to do something to mark it incompatible with older versions...
IIRC, I saw Debian bumping SO versions before...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Finn Thain]

On Sun, 15 Jun 2025, John Paul Adrian Glaubitz wrote:

> 
> Honest question, Finn: Why are you even participating in this discussion 
> when you're neither willing to acknowledge the problem nor willing to 
> help address it?
> 

You and I don't discuss much; you ignore most of what I've said, then tell 
me that what I said is off-topic. LOL.

> Do you think that you just need to bombard me with repeated statements 
> that I am going to change my mind over something that I have chewed over 
> for so long?
> 

You're quite right, I need to stop responding to repeated nonsense -- I 
will quit it.

> I think everyone in this thread has now understood that you are neither 
> willing to help resolve these issues nor are you willing to accept my 
> preferred solution that Gentoo and I are already working on.
> 

I've no idea who "everyone" is... but I'm speaking both to those 
participating in this thread and to those who know better.

As for "unwilling to help", I help where I see a need.

As for solutions, well, you have one, but you'd create more problems than 
you'd solve.

> So, what's the deal with your continued engagement?
> 

I'm not here to stop you exercising whatever power you've garnered over 
whatever domain you've claimed. (No wonder you're baffled by my presence.)

I'm here to bell the cat. What you're doing is harmful. Forking the 
packages that make up your distribution is harmful and so is fragmenting 
the ABI.

You can't improve Debian by refusing to acknowledge it's limitations. You 
can't improve the Debian experience by railroading users. You can't 
improve upstream codebases by papering over their mistakes. You can't 
improve collaboration by ignoring the advice of upstream toolchain and 
kernel developers. You can't have a stable ABI without consensus. You 
can't improve the long term prospects for the Linux/m68k project until you 
understood how it got to where it was when you arrived.

So to answer your fine question, Adrian, I continue to engage out of hope 
that you will finally realize that there are better ways to serve the 
community than the path you're on.

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Geert Uytterhoeven]

Hi Eero,

On Fri, 13 Jun 2025 at 21:29, Eero Tamminen <oak@helsinkinet.fi> wrote:
> On 13.6.2025 17.53, John Paul Adrian Glaubitz wrote:
> > On Fri, 2025-06-13 at 17:15 +0300, Eero Tamminen wrote:
> >> Wouldn't next upgrade completely break user's Debian system so it needs
> >> complete re-install?
> >
> > You would need to extract the glibc package manually from my tests. After that,
> > upgrading the system should be possible.
>
> I think quite a bit more binaries than just Glibc are needed for Debian
> upgrade tooling to work, but OK.
>
> As to other potential issues...
>
> I assume there are no m68k port packages with closed source executable
> code (FW) [1], like the other architectures (esp. x86) have & need, and
> that any code intended to work also on non-m68k platform, should be fine
> with 4-byte alignment.
>
> But what about m68k specific C/C++ and assembly code that may hard-code
> 2-byte alignment assumptions; is there any tooling to detect (potential)
> alignment issues in those?

This is one of my worries, too.
The Debian package archive is much larger than the NetBSD one...

> Or is the plan just to rely on packages' self-tests to reveal issues,
> and then track them down from there?
>
>
> [1] Are sources for "bootstra.tos" & "amiboot" anywhere, in case they
> need updates:
> https://wiki.debian.org/M68k/Installing
> https://people.debian.org/~wouter/d-i/images/20130502-06:51/tools/atari/
> https://people.debian.org/~wouter/d-i/images/20130502-06:51/tools/amiga/
> ?

https://github.com/geertu/m68kboot

I don't expect any changes would be needed for the bootstraps.
FWIW, include/uapi/linux/zorro.h already has __packed for the various
AmigaOS structs, as that was needed for APUS (support for which was
removed from the kernel a long time ago).

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Laurent Vivier]

Le 14/06/2025 à 09:21, John Paul Adrian Glaubitz a écrit :
> On Fri, 2025-06-13 at 17:24 +0200, Laurent Vivier wrote:
>> A stupid question: is this possible to remove from debian the packets
>> that are broken?
>> (I'm sorry if you already answered to this question).
> 
> Sure, we can remove Python on m68k. But whether it will still be useful
> after that remains a different question. I would argue we should rather
> totally drop the port then because Linux without Python doesn't really
> work these days.

You can see the fix for python has been merged 5 days ago...

>> Because I'm afraid that changing the ABI could cause more problems than
>> it solves.
> 
> For what exact reason? NetBSD/m68k runs with 4 bytes alignment.
> Why shouldn't this work for Linux?

The problem is not the 4 byte alignment but changing the ABI.

You will create the exact same problem you want to fix: we can guess 
some softwares are built on linux/m68k with 2byte alignment in mind. So 
once the ABI is changed, you'll have to track them to fix them.

> 
> And I have bootstrapped Debian/m68k using rebootstrap with 4 bytes alignment
> without any problems. If you think there are problems with 4 bytes alignment,
> I would like to see them reported.

Adrian, I respect all the work you do for debian ports and particularly 
on m68k, but I want to point out that this ABI change can generate more 
problems than it solves.

Thanks,
Laurent

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

Hello David,

On Fri, 2025-06-13 at 17:26 +0100, David Brownlee wrote:
> I think it is generally accepted that this would be a new ABI - a
> little similar to MIPS o32 vs n32, but with the twist that all CPUs
> support the new ABI and the goal would be for the old ABI to be
> entirely replaced.
> 
> If that is the case, the real issue would be how to manage the
> coexistence with the existing 2 byte alignment ABI port.
> 
> One option would be to give it a new port name. Sensible if this was a
> more mainstream port, but given the limited Debian engineering
> resources (waves at glaubitz@), and desire to replace the existing ABI
> entirely, I think the effort (and breakage in packages not knowing
> about the new cpu name) is probably not warranted.

Exactly.

> Given that, I think there are a number of options (of increasing effort):
> 
> 1) Just to build the new ABI port with the same name, and accept that
> attempts to run binaries between the two systems will fail without any
> specific indication
> 
> 2) Add an ELF note on new ABI binaries (similar to NetBSD/sparc64),
> and have the new system fail to run old binaries with a helpful
> message

I think this is actually a very good idea. Thanks a lot for bringing this up.

> 3) Also add a compat layer to the new system to be able to call into a
> separate set of abi libs and to versioned system calls (rewriting the
> alignment data as needed), similar to NetBSD with it's a.out (2 byte
> alignment) to ELF transition (4 byte alignment). That kernel ABI
> versioning is likely to be a.... non trivial amount of effort, but
> would allow old binaries to run transparently

This is also great, but would also require too much engineering effort,
I'm afraid.

> These stack, so 2) only makes sense if 1) is working, and 3) if 2) is working.
> 
> My understanding is glaubitz@ is working on 1). Assuming that goes
> well and unlocks a bunch of additional packages for m68k as expected,
> then I think it is worth discussing whether 2) or 3) are needed and
> who would work on them.

Agreed.

> I personally think 2) is definitely worth considering, but as I'm not
> volunteering to do the work, my opinion can be taken with a pinch of
> salt :-p

Yes, I fully agree. It's a great idea which also doesn't require mich effort.

> An elephant in the room is "what if the performance hit of 4 byte
> alignment is significant".
> 
> In that case some people may want to continue the 2 byte alignment
> port (though I think it's safe to say at this point that unless it
> reduces the performance to NS32008 leves, glaubitz@ plans to complete
> and maintain the 4 byte alignment port).

As I said before, the 2 bytes alignment port is pretty much a dead end
for Debian, so I don't really see how the performance discussion is helping
here.

Btw, I don't understand the reference to the NS32008 architecture?!

> In that case adding 2) plus the code to detect and reject new ABI
> binaries on old systems becomes if anything more interesting, and....
> I'm sure we can look forward to more animated discussions on these
> lists...

Yes!

Thanks a lot for the constructive input. Much appreciated!

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

Hello Geert,

On Sun, 2025-06-15 at 11:32 +0200, Geert Uytterhoeven wrote:
> This is one of my worries, too.
> The Debian package archive is much larger than the NetBSD one...

Debian builds currently around 11000 source packages on m68k, NetBSD builds
around 6000 packages. However, keep in mind that Debian as quite more Python
Ruby and Perl packages than NetBSD and packages them all individually.

Pythob, Ruby and Perl packages don't play any role in this discussion, except
for those which embed C/C++ or Rust code. However, these will actually run
better with 4 bytes alignment.

Adrian
> 

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

Hello Geert,

On Sun, 2025-06-15 at 11:26 +0200, Geert Uytterhoeven wrote:
> Sorry, I didn't know you have to coordinate this with the glibc project.
> But you have to do something to mark it incompatible with older versions...
> IIRC, I saw Debian bumping SO versions before...

It doesn’t really matter whether I would have to bump the SO version upstream
or in Debian. In both cases I would have to convince large projects with commercial
relevance to make invasive changes to accommodate for a compatibility change in a
hobbyist project. This will fail the same way as most attempts to get patches for
2 bytes alignment support merged upstream.

The original motivation is to make a change that will fix the alignment problem
without large changes to the source as the latter is something that would be rejected
outside the m68k scope. Both Debian and upstream would not want to integrate such
changes and rather ask us just to drop m68k support altogether.

However, I think a good compromise would be to integrate the suggestion by David
Brownlee to add an additional ELF note to block the execution of 2 bytes alignment
binaries on systems with 4 bytes alignment.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Sun, 2025-06-15 at 19:30 +1000, Finn Thain wrote:
> > Honest question, Finn: Why are you even participating in this discussion 
> > when you're neither willing to acknowledge the problem nor willing to 
> > help address it?
> > 
> 
> You and I don't discuss much; you ignore most of what I've said, then tell 
> me that what I said is off-topic. LOL.

That's because you are not even willing to understand my motivation for the
change and immediately dismiss it altogether without bringing up any suitable
alternatives.

John Klos wrote up an excellent reply to one of your many messages where he
refuted any of the arguments you brought up. Please read his reply if you
haven't done so yet.

> > Do you think that you just need to bombard me with repeated statements 
> > that I am going to change my mind over something that I have chewed over 
> > for so long?
> > 
> 
> You're quite right, I need to stop responding to repeated nonsense -- I 
> will quit it.

OK.

> > I think everyone in this thread has now understood that you are neither 
> > willing to help resolve these issues nor are you willing to accept my 
> > preferred solution that Gentoo and I are already working on.
> > 
> 
> I've no idea who "everyone" is... but I'm speaking both to those 
> participating in this thread and to those who know better.

And it's naturally only those who share your standpoint that know better,
completely ignoring that both NetBSD and Gentoo have already gone the
4 bytes alignment path or are working on it.

> As for "unwilling to help", I help where I see a need.

Then what's the point in engaging in this discussion? Do you just want to make
people feel bad? Or keep them from being productive? I don't understand your
motivation.

You say that you don't want to support the work to address this problem but
at the same time keep heckling the discussion telling me that I'm all wrong.

> As for solutions, well, you have one, but you'd create more problems than 
> you'd solve.
> 
> > So, what's the deal with your continued engagement?
> > 
> 
> I'm not here to stop you exercising whatever power you've garnered over 
> whatever domain you've claimed. (No wonder you're baffled by my presence.)

I don't need to claim the domain of Debian/m68k when there is no one else who
is willing to work on it. I'm not sure what's supposed to be controversial
about the idea that the person who does the work gets to decide how they do
it.

> I'm here to bell the cat. What you're doing is harmful. Forking the 
> packages that make up your distribution is harmful and so is fragmenting 
> the ABI.

I'm not forking any packages, I am rebuilding the source code with different
compiler settings. Forking would be changing the source which is the exact
thing that I want to avoid since most Debian and upstream maintainers don't
want to bother with intrusive changes for a hobbyist platform.

And I have no clue why you think it's harmful to make such changes to a platform
that no one is using anywhere for serious purposes. Anyone who installs Linux/m68k
these days does that because they want to play around with old computers, not because
they want to do serious work.

How is messing with a hobbyist project "harmful" in any way? That makes no sense.

> You can't improve Debian by refusing to acknowledge it's limitations.

There are no limitations in Debian. The limitations are on the currently used ABI
on Linux/m68k. And the fact that even Gentoo is making the switch to 4 bytes alignment,
something that you seem to have missed in this whole discussion, should tell you that
this isn't a Debian-only problem.

> You can't improve the Debian experience by railroading users.

I have received public and private messages from several Debian/m68k users that told
me they trust me in my decision making and thanked me for my countless effort to keep
these ports alive.

> You can't improve upstream codebases by papering over their mistakes.

You're missing the point. You are still naive enough to think that there is any chance
to fix all of these affected packages upstream. It's simply not feasible and we have
to live with it.

> You can't improve collaboration by ignoring the advice of upstream toolchain and 
> kernel developers.

What collaboration? Where is the active input from kernel and toolchain developers
on Debian/m68k? It's a hobbyist project that I am mostly running on my own.

> You can't have a stable ABI without consensus.

A stable ABI that is broken. On a hobbyist project.

> You can't improve the long term prospects for the Linux/m68k project until you 
> understood how it got to where it was when you arrived.

That's sentimental thinking. I'm not here to create a legend. I'm here to work
on a hobbyist project. You are completely blowing this out of proportion.

> So to answer your fine question, Adrian, I continue to engage out of hope 
> that you will finally realize that there are better ways to serve the 
> community than the path you're on.

Please just re-read what John Klos wrote to you and realize that it's not me who
is unwilling to actively engage to help improve the situation.

PS: At least the Python issue got fixed [1], so thanks for that.

Adrian

> [1] https://github.com/python/cpython/pull/135209

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Mon, 2025-06-16 at 08:33 +0200, Laurent Vivier wrote:
> 
> Le 14/06/2025 à 09:21, John Paul Adrian Glaubitz a écrit :
> > On Fri, 2025-06-13 at 17:24 +0200, Laurent Vivier wrote:
> > > A stupid question: is this possible to remove from debian the packets
> > > that are broken?
> > > (I'm sorry if you already answered to this question).
> > 
> > Sure, we can remove Python on m68k. But whether it will still be useful
> > after that remains a different question. I would argue we should rather
> > totally drop the port then because Linux without Python doesn't really
> > work these days.
> 
> You can see the fix for python has been merged 5 days ago...

And yet it's not just Python. The 2 bytes alignment is still the main blocker
for Rust on m68k. More and more important Python packages such as python-
cryptography are embedding Rust code these days. There is no way around it.

> > > Because I'm afraid that changing the ABI could cause more problems than
> > > it solves.
> > 
> > For what exact reason? NetBSD/m68k runs with 4 bytes alignment.
> > Why shouldn't this work for Linux?
> 
> The problem is not the 4 byte alignment but changing the ABI.

Gentoo does it as well. I haven't heard any criticism towards Gentoo, just
people unloading all their frustration on me.

> You will create the exact same problem you want to fix: we can guess 
> some softwares are built on linux/m68k with 2byte alignment in mind. So 
> once the ABI is changed, you'll have to track them to fix them.

Could you point me to these packages which assume 2 bytes alignment? I'm genuinely
interested as I would like to put these up on the wiki. So far I haven't found any.

I have used Debian's rebootstrap to create an initial set of m68k packages with
4 bytes alignment and didn't run into any problems yet.

The Gentoo developers have also successfully created a chroot with 4 bytes alignment:

https://dev.gentoo.org/~dilfridge/m68k/

I have tried it and it worked fine for me with qemu-user.

So, if there is any software that is incompatible with 4 bytes alignment on m68k, I
would like to hear about it.

> > 
> > And I have bootstrapped Debian/m68k using rebootstrap with 4 bytes alignment
> > without any problems. If you think there are problems with 4 bytes alignment,
> > I would like to see them reported.
> 
> Adrian, I respect all the work you do for debian ports and particularly 
> on m68k, but I want to point out that this ABI change can generate more 
> problems than it solves.

Then you should point me to these problems. So far, I have only heard vague warnings
but not concrete evidence that justifies your fear. In fact, I have provided more
evidence for the transition to work than any of the people in this discussion that
claim that it won't.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Laurent Vivier]

Le 16/06/2025 à 09:39, John Paul Adrian Glaubitz a écrit :
>> You will create the exact same problem you want to fix: we can guess
>> some softwares are built on linux/m68k with 2byte alignment in mind. So
>> once the ABI is changed, you'll have to track them to fix them.
> Could you point me to these packages which assume 2 bytes alignment? I'm genuinely
> interested as I would like to put these up on the wiki. So far I haven't found any.
> 
> I have used Debian's rebootstrap to create an initial set of m68k packages with
> 4 bytes alignment and didn't run into any problems yet.
> 
> The Gentoo developers have also successfully created a chroot with 4 bytes alignment:
> 
> https://dev.gentoo.org/~dilfridge/m68k/
> 
> I have tried it and it worked fine for me with qemu-user.
> 
> So, if there is any software that is incompatible with 4 bytes alignment on m68k, I
> would like to hear about it.

qemu-user is one of these softwares that know m68k has alignment of 
2byte. All the structures translated from the m68k chroot to the host 
kernel are with a 2byte alignment.

Thanks,
Laurent

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Mon, 2025-06-16 at 10:00 +0200, Laurent Vivier wrote:
> > Could you point me to these packages which assume 2 bytes alignment? I'm genuinely
> > interested as I would like to put these up on the wiki. So far I haven't found any.
> > 
> > I have used Debian's rebootstrap to create an initial set of m68k packages with
> > 4 bytes alignment and didn't run into any problems yet.
> > 
> > The Gentoo developers have also successfully created a chroot with 4 bytes alignment:
> > 
> > https://dev.gentoo.org/~dilfridge/m68k/
> > 
> > I have tried it and it worked fine for me with qemu-user.
> > 
> > So, if there is any software that is incompatible with 4 bytes alignment on m68k, I
> > would like to hear about it.
> 
> qemu-user is one of these softwares that know m68k has alignment of 
> 2byte. All the structures translated from the m68k chroot to the host 
> kernel are with a 2byte alignment.

And yet it works without any problems so far. Please try the Gentoo chroot yourself.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Laurent Vivier]

Le 16/06/2025 à 10:14, John Paul Adrian Glaubitz a écrit :
> On Mon, 2025-06-16 at 10:00 +0200, Laurent Vivier wrote:
>>> Could you point me to these packages which assume 2 bytes alignment? I'm genuinely
>>> interested as I would like to put these up on the wiki. So far I haven't found any.
>>>
>>> I have used Debian's rebootstrap to create an initial set of m68k packages with
>>> 4 bytes alignment and didn't run into any problems yet.
>>>
>>> The Gentoo developers have also successfully created a chroot with 4 bytes alignment:
>>>
>>> https://dev.gentoo.org/~dilfridge/m68k/
>>>
>>> I have tried it and it worked fine for me with qemu-user.
>>>
>>> So, if there is any software that is incompatible with 4 bytes alignment on m68k, I
>>> would like to hear about it.
>>
>> qemu-user is one of these softwares that know m68k has alignment of
>> 2byte. All the structures translated from the m68k chroot to the host
>> kernel are with a 2byte alignment.
> 
> And yet it works without any problems so far. Please try the Gentoo chroot yourself.
> 

Because most of the structures are correctly aligned by default, but 
some of them not. You must run glibc test suite and LTP to be sure there 
is no regression.

In QEMU, alignment is defined here:

include/user/abitypes.h

for m68k the values to change are:

#ifdef TARGET_M68K
#define ABI_INT_ALIGNMENT 2
#define ABI_LONG_ALIGNMENT 2
#define ABI_LLONG_ALIGNMENT 2
#endif

And there will be a problem with binfmt_misc because we can't rely on 
the ELF signature to know which qemu-user to run, the one with 2byte 
alignment or the one with 4byte alignment?

Thanks,
Laurent

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Geert Uytterhoeven]

On Mon, 16 Jun 2025 at 10:33, Laurent Vivier <laurent@vivier.eu> wrote:
> Le 16/06/2025 à 10:14, John Paul Adrian Glaubitz a écrit :
> > On Mon, 2025-06-16 at 10:00 +0200, Laurent Vivier wrote:
> >>> Could you point me to these packages which assume 2 bytes alignment? I'm genuinely
> >>> interested as I would like to put these up on the wiki. So far I haven't found any.
> >>> I have used Debian's rebootstrap to create an initial set of m68k packages with
> >>> 4 bytes alignment and didn't run into any problems yet.
> >>>
> >>> The Gentoo developers have also successfully created a chroot with 4 bytes alignment:
> >>>
> >>> https://dev.gentoo.org/~dilfridge/m68k/
> >>>
> >>> I have tried it and it worked fine for me with qemu-user.
> >>>
> >>> So, if there is any software that is incompatible with 4 bytes alignment on m68k, I
> >>> would like to hear about it.
> >>
> >> qemu-user is one of these softwares that know m68k has alignment of
> >> 2byte. All the structures translated from the m68k chroot to the host
> >> kernel are with a 2byte alignment.

The Linux kernel also knows m68k has an alignment of 2 bytes.

> > And yet it works without any problems so far. Please try the Gentoo chroot yourself.
>
> Because most of the structures are correctly aligned by default, but
> some of them not. You must run glibc test suite and LTP to be sure there
> is no regression.

Indeed.

> In QEMU, alignment is defined here:
>
> include/user/abitypes.h
>
> for m68k the values to change are:
>
> #ifdef TARGET_M68K
> #define ABI_INT_ALIGNMENT 2
> #define ABI_LONG_ALIGNMENT 2
> #define ABI_LLONG_ALIGNMENT 2
> #endif

Note that it also used to have:

    #ifdef TARGET_CRIS
    #define ABI_SHORT_ALIGNMENT 1
    #define ABI_INT_ALIGNMENT 1
    #define ABI_LONG_ALIGNMENT 1
    #define ABI_LLONG_ALIGNMENT 1
    #endif

and still has:

    #if (defined(TARGET_I386) && !defined(TARGET_X86_64)) \
        || defined(TARGET_SH4) \
        || defined(TARGET_OPENRISC) \
        || defined(TARGET_MICROBLAZE) \
        || defined(TARGET_NIOS2)
    #define ABI_LLONG_ALIGNMENT 4
    #endif

which will probably become the next victim of the 64-bit little-endian
natural-alignment monoculture...

> And there will be a problem with binfmt_misc because we can't rely on
> the ELF signature to know which qemu-user to run, the one with 2byte
> alignment or the one with 4byte alignment?

Exactly.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Mon, 2025-06-16 at 10:32 +0200, Laurent Vivier wrote:
> Because most of the structures are correctly aligned by default, but 
> some of them not. You must run glibc test suite and LTP to be sure there 
> is no regression.

Good suggestion, thanks!

> In QEMU, alignment is defined here:
> 
> include/user/abitypes.h
> 
> for m68k the values to change are:
> 
> #ifdef TARGET_M68K
> #define ABI_INT_ALIGNMENT 2
> #define ABI_LONG_ALIGNMENT 2
> #define ABI_LLONG_ALIGNMENT 2
> #endif

Thanks, this is very valuable input!

> And there will be a problem with binfmt_misc because we can't rely on 
> the ELF signature to know which qemu-user to run, the one with 2byte 
> alignment or the one with 4byte alignment?

What about the ELF note [1] that David Brownlee suggested? Can these be used?

Adrian

> [1] https://www.netbsd.org/docs/kernel/elf-notes.html

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Mon, 2025-06-16 at 10:45 +0200, Geert Uytterhoeven wrote:
> The Linux kernel also knows m68k has an alignment of 2 bytes.

Yes, we have identified (some of) these parts yet. I suggested to add a
kernel option for m68k to allow 4 bytes alignment there.

> > > And yet it works without any problems so far. Please try the Gentoo chroot yourself.
> > 
> > Because most of the structures are correctly aligned by default, but
> > some of them not. You must run glibc test suite and LTP to be sure there
> > is no regression.
> 
> Indeed.
> 
> > In QEMU, alignment is defined here:
> > 
> > include/user/abitypes.h
> > 
> > for m68k the values to change are:
> > 
> > #ifdef TARGET_M68K
> > #define ABI_INT_ALIGNMENT 2
> > #define ABI_LONG_ALIGNMENT 2
> > #define ABI_LLONG_ALIGNMENT 2
> > #endif
> 
> Note that it also used to have:
> 
>     #ifdef TARGET_CRIS
>     #define ABI_SHORT_ALIGNMENT 1
>     #define ABI_INT_ALIGNMENT 1
>     #define ABI_LONG_ALIGNMENT 1
>     #define ABI_LLONG_ALIGNMENT 1
>     #endif
> 
> and still has:
> 
>     #if (defined(TARGET_I386) && !defined(TARGET_X86_64)) \
>         || defined(TARGET_SH4) \
>         || defined(TARGET_OPENRISC) \
>         || defined(TARGET_MICROBLAZE) \
>         || defined(TARGET_NIOS2)
>     #define ABI_LLONG_ALIGNMENT 4
>     #endif
> 
> which will probably become the next victim of the 64-bit little-endian
> natural-alignment monoculture...

Geert, I think this sentiment is not fair. As I we have previously discussed, the
2 bytes alignment on Linux/m68k was never intended by the SysV ELF ABI designers
and it's based on a historical mistake.

I don't understand why it's considered to be such an unorthodox change to make
when even Commodore's own Amiga Unix uses 4 bytes alignment on the Amiga.

You know that I am the last person on the planet to lobby for deprecating old
and exotic architectures and ABIs. The motivation for this ABI change is the
result of a decade-long frustration with alignment issues on Debian/m68k which
I simply want to solve once and for all.

> > And there will be a problem with binfmt_misc because we can't rely on
> > the ELF signature to know which qemu-user to run, the one with 2byte
> > alignment or the one with 4byte alignment?
> 
> Exactly.

We could use PT_NOTE [1] for this purpose.

Adrian

> [1] https://github.com/search?q=repo%3Aqemu%2Fqemu%20PT_NOTE&type=code

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Laurent Vivier]

Le 16/06/2025 à 11:00, John Paul Adrian Glaubitz a écrit :
>> And there will be a problem with binfmt_misc because we can't rely on
>> the ELF signature to know which qemu-user to run, the one with 2byte
>> alignment or the one with 4byte alignment?
> What about the ELF note [1] that David Brownlee suggested? Can these be used?
> 
> Adrian
> 
>> [1]https://www.netbsd.org/docs/kernel/elf-notes.html

binfmt_misc doesn't use the sections to select the interpreter, but the 
128 first bytes of the file.

I think you need to change the ABI type in the ELF header:
https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format

Thanks,
Laurent

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Mon, 2025-06-16 at 11:10 +0200, Laurent Vivier wrote:
> 
> Le 16/06/2025 à 11:00, John Paul Adrian Glaubitz a écrit :
> > > And there will be a problem with binfmt_misc because we can't rely on
> > > the ELF signature to know which qemu-user to run, the one with 2byte
> > > alignment or the one with 4byte alignment?
> > What about the ELF note [1] that David Brownlee suggested? Can these be used?
> > 
> > Adrian
> > 
> > > [1]https://www.netbsd.org/docs/kernel/elf-notes.html
> 
> binfmt_misc doesn't use the sections to select the interpreter, but the 
> 128 first bytes of the file.
> 
> I think you need to change the ABI type in the ELF header:
> https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format

How does binfmt_misc handle the various MIPS ABIs then?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Laurent Vivier]

Le 16/06/2025 à 11:15, John Paul Adrian Glaubitz a écrit :
> On Mon, 2025-06-16 at 11:10 +0200, Laurent Vivier wrote:
>>
>> Le 16/06/2025 à 11:00, John Paul Adrian Glaubitz a écrit :
>>>> And there will be a problem with binfmt_misc because we can't rely on
>>>> the ELF signature to know which qemu-user to run, the one with 2byte
>>>> alignment or the one with 4byte alignment?
>>> What about the ELF note [1] that David Brownlee suggested? Can these be used?
>>>
>>> Adrian
>>>
>>>> [1]https://www.netbsd.org/docs/kernel/elf-notes.html
>>
>> binfmt_misc doesn't use the sections to select the interpreter, but the
>> 128 first bytes of the file.
>>
>> I think you need to change the ABI type in the ELF header:
>> https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format
> 
> How does binfmt_misc handle the various MIPS ABIs then?

It doesn't and it's a problem.

Thanks,
Laurent

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Mon, 2025-06-16 at 11:26 +0200, Laurent Vivier wrote:
> > > binfmt_misc doesn't use the sections to select the interpreter, but the
> > > 128 first bytes of the file.
> > > 
> > > I think you need to change the ABI type in the ELF header:
> > > https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format
> > 
> > How does binfmt_misc handle the various MIPS ABIs then?
> 
> It doesn't and it's a problem.

Very interesting. Is there a bug report for that?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Laurent Vivier]

Le 16/06/2025 à 11:32, John Paul Adrian Glaubitz a écrit :
> On Mon, 2025-06-16 at 11:26 +0200, Laurent Vivier wrote:
>>>> binfmt_misc doesn't use the sections to select the interpreter, but the
>>>> 128 first bytes of the file.
>>>>
>>>> I think you need to change the ABI type in the ELF header:
>>>> https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format
>>>
>>> How does binfmt_misc handle the various MIPS ABIs then?
>>
>> It doesn't and it's a problem.
> 
> Very interesting. Is there a bug report for that?
> 

It’s not a bug in binfmt_misc. binfmt_misc is simply a loader that picks 
an interpreter based on a file’s signature.

The problem comes from a poor design choice in MIPS, which chose to use 
the same ABI type identifier for different ABI variants.

Thanks,
Laurent

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Geert Uytterhoeven]

Hi Laurent,

On Mon, 16 Jun 2025 at 11:16, Laurent Vivier <laurent@vivier.eu> wrote:
> Le 16/06/2025 à 11:00, John Paul Adrian Glaubitz a écrit :
> >> And there will be a problem with binfmt_misc because we can't rely on
> >> the ELF signature to know which qemu-user to run, the one with 2byte
> >> alignment or the one with 4byte alignment?
> > What about the ELF note [1] that David Brownlee suggested? Can these be used?
> >
> > Adrian
> >
> >> [1]https://www.netbsd.org/docs/kernel/elf-notes.html
>
> binfmt_misc doesn't use the sections to select the interpreter, but the
> 128 first bytes of the file.
>
> I think you need to change the ABI type in the ELF header:
> https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format

Interesting....

Does any system actually use ABI (byte 7) = 3 (Linux)?
All of amd64/arm/arm64/ia64/i386/m68k/microblaze/mips(el)/powerpc/risvc/s390/sh/sparc
seem to use 0 (SYSV).

#define ELFOSABI_NONE   0
#define ELFOSABI_LINUX  3

Ah, parisc does. And C6x uses 0x40.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Laurent Vivier]

Le 16/06/2025 à 12:07, Geert Uytterhoeven a écrit :
> Hi Laurent,
> 
> On Mon, 16 Jun 2025 at 11:16, Laurent Vivier <laurent@vivier.eu> wrote:
>> Le 16/06/2025 à 11:00, John Paul Adrian Glaubitz a écrit :
>>>> And there will be a problem with binfmt_misc because we can't rely on
>>>> the ELF signature to know which qemu-user to run, the one with 2byte
>>>> alignment or the one with 4byte alignment?
>>> What about the ELF note [1] that David Brownlee suggested? Can these be used?
>>>
>>> Adrian
>>>
>>>> [1]https://www.netbsd.org/docs/kernel/elf-notes.html
>>
>> binfmt_misc doesn't use the sections to select the interpreter, but the
>> 128 first bytes of the file.
>>
>> I think you need to change the ABI type in the ELF header:
>> https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format
> 
> Interesting....
> 
> Does any system actually use ABI (byte 7) = 3 (Linux)?
> All of amd64/arm/arm64/ia64/i386/m68k/microblaze/mips(el)/powerpc/risvc/s390/sh/sparc
> seem to use 0 (SYSV).
> 
> #define ELFOSABI_NONE   0
> #define ELFOSABI_LINUX  3
> 
> Ah, parisc does. And C6x uses 0x40.
> 

You're right. But to update the ELF header with the information we are 
using 4 bytes alignment perhaps we should use instead the e_flags entry?

It's architecture dependent and it seems used by MIPS (EF_MIPS_ABI2 
?)... so MIPS is OK, I think the problem is I don't use the correct 
binfmt_misc mask...

Thanks,
Laurent

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Mon, 2025-06-16 at 12:07 +0200, Geert Uytterhoeven wrote:
> > I think you need to change the ABI type in the ELF header:
> > https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format
> 
> Interesting....
> 
> Does any system actually use ABI (byte 7) = 3 (Linux)?
> All of amd64/arm/arm64/ia64/i386/m68k/microblaze/mips(el)/powerpc/risvc/s390/sh/sparc
> seem to use 0 (SYSV).
> 
> #define ELFOSABI_NONE   0
> #define ELFOSABI_LINUX  3

Strictly speaking, a value of 0x00 indicates SysV ABI [1].

But maybe we could use 0x03 for Linux/m68k with 4 bytes alignment.

Adrian

> [1] https://en.wikipedia.org/wiki/Executable_and_Linkable_Format#ELF_header

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Laurent Vivier]

On 16/06/2025 13:01, John Paul Adrian Glaubitz wrote:
> On Mon, 2025-06-16 at 12:07 +0200, Geert Uytterhoeven wrote:
>>> I think you need to change the ABI type in the ELF header:
>>> https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format
>>
>> Interesting....
>>
>> Does any system actually use ABI (byte 7) = 3 (Linux)?
>> All of amd64/arm/arm64/ia64/i386/m68k/microblaze/mips(el)/powerpc/risvc/s390/sh/sparc
>> seem to use 0 (SYSV).
>>
>> #define ELFOSABI_NONE   0
>> #define ELFOSABI_LINUX  3
> 
> Strictly speaking, a value of 0x00 indicates SysV ABI [1].
> 
> But maybe we could use 0x03 for Linux/m68k with 4 bytes alignment.
> 
> Adrian
> 
>> [1] https://en.wikipedia.org/wiki/Executable_and_Linkable_Format#ELF_header
> 

I think an e_flags with a new value like EF_M68K_ABI2 would be more appropriate.

Thanks,
Laurent

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Mon, 2025-06-16 at 13:05 +0200, Laurent Vivier wrote:
> I think an e_flags with a new value like EF_M68K_ABI2 would be more appropriate.

How is it currently used on m68k and does QEMU use it? I think that would be
certainly a way to go.

FWIW, I checked EI_OSABI on hppa out of curiosity:

glaubitz@panama:~$ uname -a
Linux panama 6.12.32-parisc64 #1 SMP Debian 6.12.32-1 (2025-06-07) parisc64 GNU/Linux
glaubitz@panama:~$ readelf -h /bin/bash|grep "OS/ABI"
  OS/ABI:                            UNIX - GNU
glaubitz@panama:~$

Compare that to x86_64:

glaubitz@suse-laptop:~> uname -a
Linux suse-laptop 6.15.1-1-default #1 SMP PREEMPT_DYNAMIC Thu Jun  5 14:29:05 UTC 2025 (75961ad) x86_64 x86_64 x86_64 GNU/Linux
glaubitz@suse-laptop:~> readelf -h /bin/bash|grep "OS/ABI"
  OS/ABI:                            UNIX - System V
glaubitz@suse-laptop:~>

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Mon, 2025-06-16 at 13:10 +0200, John Paul Adrian Glaubitz wrote:
> On Mon, 2025-06-16 at 13:05 +0200, Laurent Vivier wrote:
> > I think an e_flags with a new value like EF_M68K_ABI2 would be more appropriate.
> 
> How is it currently used on m68k and does QEMU use it? I think that would be
> certainly a way to go.

So, it seems that this is what's being used on MIPS:

https://elixir.bootlin.com/linux/v6.15.2/source/arch/mips/include/asm/elf.h#L289

Looks like this would be the way to go!

Thanks Laurent for digging this out! The discussion definitely yields some results ;-).

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Laurent Vivier]

On 16/06/2025 13:10, John Paul Adrian Glaubitz wrote:
> On Mon, 2025-06-16 at 13:05 +0200, Laurent Vivier wrote:
>> I think an e_flags with a new value like EF_M68K_ABI2 would be more appropriate.
> 
> How is it currently used on m68k and does QEMU use it? I think that would be
> certainly a way to go.
> 

It's not used by m68k.

It's only used by MIPS.

In QEMU see linux-user/elfload.c:

#ifdef TARGET_ABI_MIPSN32
#define elf_check_abi(x) ((x) & EF_MIPS_ABI2)
#else
#define elf_check_abi(x) (!((x) & EF_MIPS_ABI2))
#endif

#ifndef elf_check_abi
#define elf_check_abi(x) (1)
#endif

/* Verify the portions of EHDR outside of E_IDENT for the target.
    This has to wait until after bswapping the header.  */
static bool elf_check_ehdr(struct elfhdr *ehdr)
{
     return (elf_check_arch(ehdr->e_machine)
             && elf_check_abi(ehdr->e_flags)
             && ehdr->e_ehsize == sizeof(struct elfhdr)
             && ehdr->e_phentsize == sizeof(struct elf_phdr)
             && (ehdr->e_type == ET_EXEC || ehdr->e_type == ET_DYN));
}
...

static void load_elf_image(const char *image_name, const ImageSource *src,
                            struct image_info *info, struct elfhdr *ehdr,
                            char **pinterp_name)
...
     if (!elf_check_ehdr(ehdr)) {
         error_setg(&err, "Invalid ELF image for this architecture");
         goto exit_errmsg;
     }
...

Thanks,
Laurent

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Geert Uytterhoeven]

Hi Adrian,

On Mon, 16 Jun 2025 at 13:48, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On Thu, 2025-06-12 at 08:25 +0000, Administrator @ R·V·E wrote:
> > Thanks for your great hard work and efforts to mantain the various and now
> > considered exotic architectures running Debian, Adrian!
>
> Thanks, and you're welcome. Unfortunately, some people like Finn and Eero don't
> appreciate these efforts and seem to think that this all comes at zero costs.

Please calm down...
Thanks!

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

Hello Geert,

On Mon, 2025-06-16 at 13:54 +0200, Geert Uytterhoeven wrote:
> On Mon, 16 Jun 2025 at 13:48, John Paul Adrian Glaubitz
> <glaubitz@physik.fu-berlin.de> wrote:
> > On Thu, 2025-06-12 at 08:25 +0000, Administrator @ R·V·E wrote:
> > > Thanks for your great hard work and efforts to mantain the various and now
> > > considered exotic architectures running Debian, Adrian!
> > 
> > Thanks, and you're welcome. Unfortunately, some people like Finn and Eero don't
> > appreciate these efforts and seem to think that this all comes at zero costs.
> 
> Please calm down...

I wrote that message on Friday. Odd that your email client claims it was sent today.
Besides that, I would like to point again at what John Klos wrote in reply to Finn [1].

Adrian

> [1] https://lists.debian.org/debian-68k/2025/05/msg00051.html

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Geert Uytterhoeven]

Hi Adrian,

On Mon, 16 Jun 2025 at 14:21, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> I wrote that message on Friday. Odd that your email client claims it was sent today.
> Besides that, I would like to point again at what John Klos wrote in reply to Finn [1].

The increased email traffic during the Linux kernel merge window
causes lots of delayed email :-(

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Jason Thorpe]

> On Jun 16, 2025, at 2:10 AM, Laurent Vivier <laurent@vivier.eu> wrote:
> 
> I think you need to change the ABI type in the ELF header:
> https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format

4-byte alignment binaries should have ELFOSABI_SYSV (0) (since that ABI spec is where the 4 byte alignment comes from).  If Linux/m68k is already using that, then those binaries are broken by definition.

Let’s hope existing Linux/m68k binaries are using ELFOSABI_LINUX / ELFOSABI_GNU (3) (sorry, I don’t have any handy to check).

If the existing binaries correctly label themselves has having the Linux-specific ABI, then this is trivial and there’s no reason to use a note to differentiate them.

-- thorpej

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Jason Thorpe]

> On Jun 16, 2025, at 4:01 AM, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:
> 
> Strictly speaking, a value of 0x00 indicates SysV ABI [1].
> 
> But maybe we could use 0x03 for Linux/m68k with 4 bytes alignment.

I mean, that would be wrong, but if you’ve been pained into a corner...

-- thorpej

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

Hi Jason,

On Mon, 2025-06-16 at 07:43 -0700, Jason Thorpe wrote:
> > On Jun 16, 2025, at 2:10 AM, Laurent Vivier <laurent@vivier.eu> wrote:
> > 
> > I think you need to change the ABI type in the ELF header:
> > https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format
> 
> 4-byte alignment binaries should have ELFOSABI_SYSV (0) (since that ABI spec
> is where the 4 byte alignment comes from).  If Linux/m68k is already using that,
> then those binaries are broken by definition.

Unfortunately, that's exactly the case:

root@mitchy:~# uname -a
Linux mitchy 6.15.0-rc2-virt #1 Thu May  1 10:27:28 UTC 2025 m68k GNU/Linux
root@mitchy:~# readelf -h /bin/bash |grep "OS/ABI"
  OS/ABI:                            UNIX - System V
root@mitchy:~#

> Let’s hope existing Linux/m68k binaries are using ELFOSABI_LINUX / ELFOSABI_GNU (3)
> (sorry, I don’t have any handy to check).

hppa is using it:

glaubitz@panama:~$ 
glaubitz@panama:~$ uname -a
Linux panama 6.12.32-parisc64 #1 SMP Debian 6.12.32-1 (2025-06-07) parisc64 GNU/Linux
glaubitz@panama:~$ readelf -h /bin/bash|grep "OS/ABI"
  OS/ABI:                            UNIX - GNU
glaubitz@panama:~$

> If the existing binaries correctly label themselves has having the Linux-specific ABI,
> then this is trivial and there’s no reason to use a note to differentiate them.

I don't have a strong preference as both of them are used in the Linux kernel.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Preliminary results - was: Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

Hi Geert,

On Mon, 2025-06-16 at 14:29 +0200, Geert Uytterhoeven wrote:
> Hi Adrian,
> 
> On Mon, 16 Jun 2025 at 14:21, John Paul Adrian Glaubitz
> <glaubitz@physik.fu-berlin.de> wrote:
> > I wrote that message on Friday. Odd that your email client claims it was sent today.
> > Besides that, I would like to point again at what John Klos wrote in reply to Finn [1].
> 
> The increased email traffic during the Linux kernel merge window
> causes lots of delayed email :-(

Hmm, I see. Let's cool this discussion down a bit and summarize what we got so far:

To summarize:

- the ELF header provides provides the e_ident and e_flags fields which could be
  used for identifying a Linux/m68k system using the 4 bytes alignment ABI
- MIPS uses e_flags for differentiating its ABIs
- PA-RISC sets e_ident to 0x03 (Linux) while every other arch uses 0x00 (SysV ABI)
- qemu-user needs to be patched to deal with the changed alignment (include/user/abitypes.h)
- the kernel needs to be patched to deal with the changed alignment (arch/m68k/kernel/signal.c)
- NetBSD uses an emulation layer which allows 2 bytes alignment a.out executables on an
  ELF system with 4 bytes alignment
- glibc needs to be patched in sysdeps/m68k/utmp-size.h
- gcc needs to be patched in gcc/config/m68k/linux.h (BIGGEST_ALIGNMENT to 64, EMPTY_FIELD_BOUNDARY
  and STACK_BOUNDARY to 32, see netbsd-elf.h)
- the glibc and gcc testsuites should be run in a 4 bytes alignment to check for regressions

Anything else I'm missing?

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Finn Thain]

[-- Attachment #1: Type: text/plain, Size: 921 bytes --]


On Mon, 16 Jun 2025, Jason Thorpe wrote:

> 
> > On Jun 16, 2025, at 2:10 AM, Laurent Vivier <laurent@vivier.eu> wrote:
> > 
> > I think you need to change the ABI type in the ELF header: 
> > https://fr.wikipedia.org/wiki/Executable_and_Linkable_Format
> 
> 4-byte alignment binaries should have ELFOSABI_SYSV (0) (since that ABI 
> spec is where the 4 byte alignment comes from).  If Linux/m68k is 
> already using that, then those binaries are broken by definition.
> 
> Let’s hope existing Linux/m68k binaries are using ELFOSABI_LINUX / 
> ELFOSABI_GNU (3) (sorry, I don’t have any handy to check).
> 
> If the existing binaries correctly label themselves has having the 
> Linux-specific ABI, then this is trivial and there’s no reason to use a 
> note to differentiate them.
> 

Do you know of a good solution for this open bug?
https://sourceware.org/bugzilla/show_bug.cgi?id=30273

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Finn Thain]

On Mon, 16 Jun 2025, John Paul Adrian Glaubitz wrote:

[repeated falacies snipped]

> 
> How is messing with a hobbyist project "harmful" in any way? That makes 
> no sense.
> 

If your port was a pure hobbyist project, you would never have brought 
your complaint to the upstream mailing lists, where developers have to 
work with ALL interested parties and make the necessary compromises.

But, as usual, you're trying to have it both ways. You pretend that wiping 
wiping your slate clean and starting over doesn't impact anyone else. But 
then you complain when the upstream projects don't care to invest effort 
into your scheme.

The way to find a compromise is to build the thing you need, and then, if 
any of it is found to be useful upstream, send patches! That's how this 
process has always worked, has it not?

Moreover, to the extent that those patches get merged, we will have the 
beginnings of a second ABI with a second tuple. To the extend that those 
patches get rejected, you will have a fork on your hands.

So, some upstream developers will have to support both ABIs (for them, 
you've just created work). Other developers will have to choose between 
either one (for them, you've just make collaboration more difficult).

This is a lose/lose proposition. And if you think I'm wrong about that, 
please just send patches and demonstrate why.

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Wed, 2025-06-18 at 13:19 +1000, Finn Thain wrote:
> Do you know of a good solution for this open bug?
> https://sourceware.org/bugzilla/show_bug.cgi?id=30273

The proper solution would be to actually adhere to the official SVR4 ABI
when declaring elfosabi == GDB_OSABI_SVR4 and using GDB_OSABI_LINUX for
the old Linux ABI.

This bug is another example why it was not a good idea to ignore the official
AT&T System V ABI ELF specification as it proves that independent upstream
projects look at the actual official specification when implementing code.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Wed, 2025-06-18 at 13:50 +1000, Finn Thain wrote:
> > How is messing with a hobbyist project "harmful" in any way? That makes 
> > no sense.
> > 
> 
> If your port was a pure hobbyist project, you would never have brought 
> your complaint to the upstream mailing lists, where developers have to 
> work with ALL interested parties and make the necessary compromises.

Can you list ALL interested parties, please?

I only know about Gentoo and Debian and both want to make the switch.

> But, as usual, you're trying to have it both ways. You pretend that wiping 
> wiping your slate clean and starting over doesn't impact anyone else. But 
> then you complain when the upstream projects don't care to invest effort 
> into your scheme.

Again, can you list the other downstream projects that would be affected and
that oppose this change? Please come with actual evidence instead of just
remaining vague.

> The way to find a compromise is to build the thing you need, and then, if 
> any of it is found to be useful upstream, send patches! That's how this 
> process has always worked, has it not?

I have never denied that. The problem here is that I started a discussion to
resolve a longstanding problem with the m68k port and you immediately started
shooting at it instead of trying to work something out together.

> Moreover, to the extent that those patches get merged, we will have the 
> beginnings of a second ABI with a second tuple. To the extend that those 
> patches get rejected, you will have a fork on your hands.

I won't have a problem with maintaining the fork. As I have repeatedly said,
the Gentoo people are working on the same change, so it's more like the upstream
developers that would exclude themselves.

> So, some upstream developers will have to support both ABIs (for them, 
> you've just created work). Other developers will have to choose between 
> either one (for them, you've just make collaboration more difficult).

You're again being vague. You talk about Linux/m68k as if there were dozens
of downstream distributions and projects when there is in fact just Debian
and Gentoo which both, as I have said countless times now, want to make the
switch.

So, I have no idea what these other mystical downstream projects should be.

> This is a lose/lose proposition. And if you think I'm wrong about that, 
> please just send patches and demonstrate why.

I have received multiple messages now, off- and on-list, from users that are
supporting my efforts as they see the value in making software more useful
to users instead of just insisting on adhering to a broken ABI that no one
really cares about anymore in the year 2025.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Geert Uytterhoeven]

Hi Adrian,

On Wed, 18 Jun 2025 at 11:16, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On Wed, 2025-06-18 at 13:50 +1000, Finn Thain wrote:
> > > How is messing with a hobbyist project "harmful" in any way? That makes
> > > no sense.
> >
> > If your port was a pure hobbyist project, you would never have brought
> > your complaint to the upstream mailing lists, where developers have to
> > work with ALL interested parties and make the necessary compromises.
>
> Can you list ALL interested parties, please?
>
> I only know about Gentoo and Debian and both want to make the switch.

Buildroot? Which is probably where the real product users (using Coldfire)
are hiding...

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Wed, 2025-06-18 at 11:36 +0200, Geert Uytterhoeven wrote:
> > I only know about Gentoo and Debian and both want to make the switch.
> 
> Buildroot? Which is probably where the real product users (using Coldfire)
> are hiding...

Coldfire already uses a different alignment (for the stack):

/* ColdFire and fido strongly prefer a 32-bit aligned stack.  */
#define PREFERRED_STACK_BOUNDARY \
  ((TARGET_COLDFIRE || TARGET_FIDOA) ? 32 : 16)

It's instruction set is also not fully compatible AFAIK.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Geert Uytterhoeven]

Hi Adrian,

On Wed, 18 Jun 2025 at 11:49, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On Wed, 2025-06-18 at 11:36 +0200, Geert Uytterhoeven wrote:
> > > I only know about Gentoo and Debian and both want to make the switch.
> >
> > Buildroot? Which is probably where the real product users (using Coldfire)
> > are hiding...
>
> Coldfire already uses a different alignment (for the stack):
>
> /* ColdFire and fido strongly prefer a 32-bit aligned stack.  */
> #define PREFERRED_STACK_BOUNDARY \
>   ((TARGET_COLDFIRE || TARGET_FIDOA) ? 32 : 16)
>
> It's instruction set is also not fully compatible AFAIK.

Sure, but you will impact it regardless.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

Hello Geert,

On Wed, 2025-06-18 at 11:56 +0200, Geert Uytterhoeven wrote:
> > Coldfire already uses a different alignment (for the stack):
> > 
> > /* ColdFire and fido strongly prefer a 32-bit aligned stack.  */
> > #define PREFERRED_STACK_BOUNDARY \
> >   ((TARGET_COLDFIRE || TARGET_FIDOA) ? 32 : 16)
> > 
> > It's instruction set is also not fully compatible AFAIK.
> 
> Sure, but you will impact it regardless.

Could you please elaborate this a bit more, please?

Coldfire is handled as a separate target via TARGET_COLDFIRE in GCC, so we
would certainly be able to toggle the alignment settings independent of
what's done on classic m68k. In the Linux kernel, Coldfire is also a separate
arch, so the alignment settings can also be handled there separately if necessary.

It's not really necessary to enforce this on Coldfire. However, since buildroot
builds completely from source, it wouldn't even be a problem to change the alignment
there as well.

PS: I would like to lead a discussion on how to implement this properly and
not continue to have one why this shouldn't be done as the latter is continuing
to take a lot of energy.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Finn Thain]

On Wed, 18 Jun 2025, John Paul Adrian Glaubitz wrote:

> 
> I would like to lead a discussion ...
> 

I would like to read a patch ...

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Greg Ungerer]

Hi Adrian,

On 18/6/25 20:04, John Paul Adrian Glaubitz wrote:
> Hello Geert,
> 
> On Wed, 2025-06-18 at 11:56 +0200, Geert Uytterhoeven wrote:
>>> Coldfire already uses a different alignment (for the stack):
>>>
>>> /* ColdFire and fido strongly prefer a 32-bit aligned stack.  */
>>> #define PREFERRED_STACK_BOUNDARY \
>>>    ((TARGET_COLDFIRE || TARGET_FIDOA) ? 32 : 16)
>>>
>>> It's instruction set is also not fully compatible AFAIK.
>>
>> Sure, but you will impact it regardless.
> 
> Could you please elaborate this a bit more, please?
> 
> Coldfire is handled as a separate target via TARGET_COLDFIRE in GCC, so we
> would certainly be able to toggle the alignment settings independent of
> what's done on classic m68k.

The net out is that it is the same gcc compiler, m68k-linux-gcc.
ColdFire just needs specific code generation via command line switches,
like -m5200 (or -m5206e or -m5307 or -mcfv4e, etc). This is the same way
you would specify 680x0 level - m68020, -m68030, etc.

The bulk of the instruction set is the same. Asm code will look totally
familiar to anyone who knows m68k :-)   One notable difference is that
there is a more limited set addressing modes for some instructions.

FWIW ColdFire currently uses the same ABI as all other m68k, so it uses
2-byte alignment today.


> In the Linux kernel, Coldfire is also a separate
> arch, so the alignment settings can also be handled there separately if necessary.

ColdFire is not handled as a separate architecture in linux, it is just a
variant of m68k - so uses arch/m68k in the source.


> It's not really necessary to enforce this on Coldfire. However, since buildroot
> builds completely from source, it wouldn't even be a problem to change the alignment
> there as well.

Yes, that is totally right in my experience. Certainly in my ColdFire work
it is pretty much always a build-everything approach via buildroot or similar.
I wouldn't think an ABI change would actually worry too many ColdFire uses,
they don't use distributions like debian on them. (I would love to hear from
anyone who does!).

Regards
Greg



> PS: I would like to lead a discussion on how to implement this properly and
> not continue to have one why this shouldn't be done as the latter is continuing
> to take a lot of energy.
> 
> Adrian
> 

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

Hi Greg,

On Wed, 2025-06-18 at 22:21 +1000, Greg Ungerer wrote:
> > Could you please elaborate this a bit more, please?
> > 
> > Coldfire is handled as a separate target via TARGET_COLDFIRE in GCC, so we
> > would certainly be able to toggle the alignment settings independent of
> > what's done on classic m68k.
> 
> The net out is that it is the same gcc compiler, m68k-linux-gcc.
> ColdFire just needs specific code generation via command line switches,
> like -m5200 (or -m5206e or -m5307 or -mcfv4e, etc). This is the same way
> you would specify 680x0 level - m68020, -m68030, etc.

Yes, but there is a TARGET_COLDFIRE macro as I mentioned above which could
be used to trigger which alignment to use by default. I don't see how that
would complicate things.

> The bulk of the instruction set is the same. Asm code will look totally
> familiar to anyone who knows m68k :-)   One notable difference is that
> there is a more limited set addressing modes for some instructions.

True, but you won't be able to run any classic m68k binaries on ColdFire
and the other way around, are you?

> FWIW ColdFire currently uses the same ABI as all other m68k, so it uses
> 2-byte alignment today.

I know. And one user on the LKML has already demonstrated that his Coldfire
board booted fine with buildroot set to 4 bytes alignment.

> > In the Linux kernel, Coldfire is also a separate
> > arch, so the alignment settings can also be handled there separately if necessary.
> 
> ColdFire is not handled as a separate architecture in linux, it is just a
> variant of m68k - so uses arch/m68k in the source.

Well, it's a separate sub-architecture, similar to what's done for sh3/sh4 on sh
or the various ARM flavors. My point was just that there is a way to separate
classic m68k and Coldfire code if necessary.

> > It's not really necessary to enforce this on Coldfire. However, since buildroot
> > builds completely from source, it wouldn't even be a problem to change the alignment
> > there as well.
> 
> Yes, that is totally right in my experience. Certainly in my ColdFire work
> it is pretty much always a build-everything approach via buildroot or similar.
> I wouldn't think an ABI change would actually worry too many ColdFire uses,
> they don't use distributions like debian on them. (I would love to hear from
> anyone who does!).

Thanks a lot for confirming this!

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Geert Uytterhoeven]

Hi Adrian,

On Wed, 18 Jun 2025 at 14:27, John Paul Adrian Glaubitz
<glaubitz@physik.fu-berlin.de> wrote:
> On Wed, 2025-06-18 at 22:21 +1000, Greg Ungerer wrote:
> > > Could you please elaborate this a bit more, please?
> > >
> > > Coldfire is handled as a separate target via TARGET_COLDFIRE in GCC, so we
> > > would certainly be able to toggle the alignment settings independent of
> > > what's done on classic m68k.
> >
> > The net out is that it is the same gcc compiler, m68k-linux-gcc.
> > ColdFire just needs specific code generation via command line switches,
> > like -m5200 (or -m5206e or -m5307 or -mcfv4e, etc). This is the same way
> > you would specify 680x0 level - m68020, -m68030, etc.
>
> Yes, but there is a TARGET_COLDFIRE macro as I mentioned above which could
> be used to trigger which alignment to use by default. I don't see how that
> would complicate things.
>
> > The bulk of the instruction set is the same. Asm code will look totally
> > familiar to anyone who knows m68k :-)   One notable difference is that
> > there is a more limited set addressing modes for some instructions.
>
> True, but you won't be able to run any classic m68k binaries on ColdFire
> and the other way around, are you?

IIIRC if you use a proper subset of the user mode instructions, you
can create binaries that run on both.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

On Wed, 2025-06-18 at 14:54 +0200, Geert Uytterhoeven wrote:
> > True, but you won't be able to run any classic m68k binaries on ColdFire
> > and the other way around, are you?
> 
> IIIRC if you use a proper subset of the user mode instructions, you
> can create binaries that run on both.

OK, but I assume that's not really a relevant usecase.

And since Greg already said that he is not generally rejecting the idea of
switching the default alignment, we should rather discuss what would be
the best way to implement this without causing a lot of headache.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Greg Ungerer]

Hi Geert,

On 18/6/25 22:54, Geert Uytterhoeven wrote:
> Hi Adrian,
> 
> On Wed, 18 Jun 2025 at 14:27, John Paul Adrian Glaubitz
> <glaubitz@physik.fu-berlin.de> wrote:
>> On Wed, 2025-06-18 at 22:21 +1000, Greg Ungerer wrote:
>>>> Could you please elaborate this a bit more, please?
>>>>
>>>> Coldfire is handled as a separate target via TARGET_COLDFIRE in GCC, so we
>>>> would certainly be able to toggle the alignment settings independent of
>>>> what's done on classic m68k.
>>>
>>> The net out is that it is the same gcc compiler, m68k-linux-gcc.
>>> ColdFire just needs specific code generation via command line switches,
>>> like -m5200 (or -m5206e or -m5307 or -mcfv4e, etc). This is the same way
>>> you would specify 680x0 level - m68020, -m68030, etc.
>>
>> Yes, but there is a TARGET_COLDFIRE macro as I mentioned above which could
>> be used to trigger which alignment to use by default. I don't see how that
>> would complicate things.
>>
>>> The bulk of the instruction set is the same. Asm code will look totally
>>> familiar to anyone who knows m68k :-)   One notable difference is that
>>> there is a more limited set addressing modes for some instructions.
>>
>> True, but you won't be able to run any classic m68k binaries on ColdFire
>> and the other way around, are you?
> 
> IIIRC if you use a proper subset of the user mode instructions, you
> can create binaries that run on both.

You might be right on that. If you chose the lowest common denominator
of ColdFire code generation, -m5200, then I seem to recall for user
space that would just be a subset of traditional 68k.

Regards
Greg

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Finn Thain]

On Wed, 18 Jun 2025, John Paul Adrian Glaubitz wrote:

> On Wed, 2025-06-18 at 13:19 +1000, Finn Thain wrote:
> 
> > Do you know of a good solution for this open bug?
> > https://sourceware.org/bugzilla/show_bug.cgi?id=30273
> 
> The proper solution would be to actually adhere to the official SVR4 ABI 
> when declaring elfosabi == GDB_OSABI_SVR4 and using GDB_OSABI_LINUX for 
> the old Linux ABI.
> 
> This bug is another example why it was not a good idea to ignore the 
> official AT&T System V ABI ELF specification as it proves that 
> independent upstream projects look at the actual official specification 
> when implementing code.
> 

I think what you meant to say was, "no".

Interesting how, after a year or two of agitating and bloviating, you 
don't actually have a solution that would permit two co-existent 
m68k-linux ELF ABIs. I wonder what you real aim was?

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Finn Thain]

On Wed, 18 Jun 2025, John Paul Adrian Glaubitz wrote:

> On Wed, 2025-06-18 at 13:50 +1000, Finn Thain wrote:
> > > How is messing with a hobbyist project "harmful" in any way? That makes 
> > > no sense.
> > > 
> > 
> > If your port was a pure hobbyist project, you would never have brought 
> > your complaint to the upstream mailing lists, where developers have to 
> > work with ALL interested parties and make the necessary compromises.
> 
> Can you list ALL interested parties, please?
> 
> I only know about Gentoo and Debian and both want to make the switch.
> 

That's what code review is for. I'd be happy to show you how your patches 
will have an adverse affect on others, once you post them all. (And I mean 
ALL patches -- including the ones you expect Debian to carry.)

> > But, as usual, you're trying to have it both ways. You pretend that 
> > wiping wiping your slate clean and starting over doesn't impact anyone 
> > else. But then you complain when the upstream projects don't care to 
> > invest effort into your scheme.
> 
> Again, can you list the other downstream projects that would be affected 
> and that oppose this change? Please come with actual evidence instead of 
> just remaining vague.
> 

Again, please post patches instead of "remaining vague". Also, FYI, the 
development process doesn't demand lists. Just one regression would be 
sufficient.

> > The way to find a compromise is to build the thing you need, and then, 
> > if any of it is found to be useful upstream, send patches! That's how 
> > this process has always worked, has it not?
> 
> I have never denied that. The problem here is that I started a 
> discussion to resolve a longstanding problem with the m68k port and you 
> immediately started shooting at it instead of trying to work something 
> out together.
> 

Cool story. But the record shows that you went on the offensive, 
threatening to break the ABI, and I merely responded.

> > Moreover, to the extent that those patches get merged, we will have 
> > the beginnings of a second ABI with a second tuple. To the extend that 
> > those patches get rejected, you will have a fork on your hands.
> 
> I won't have a problem with maintaining the fork. As I have repeatedly 
> said, the Gentoo people are working on the same change, so it's more 
> like the upstream developers that would exclude themselves.
> 

And yet, two days prior, you wrote, "I'm not forking any packages". The 
emptiness of that commitment is abundantly clear now.

> > So, some upstream developers will have to support both ABIs (for them, 
> > you've just created work). Other developers will have to choose 
> > between either one (for them, you've just make collaboration more 
> > difficult).
> 
> You're again being vague. You talk about Linux/m68k as if there were 
> dozens of downstream distributions and projects when there is in fact 
> just Debian and Gentoo which both, as I have said countless times now, 
> want to make the switch.
> 
> So, I have no idea what these other mystical downstream projects should 
> be.
> 

Where did I mention "projects"? You need to read the messages you reply 
to.

> > This is a lose/lose proposition. And if you think I'm wrong about 
> > that, please just send patches and demonstrate why.
> 
> I have received multiple messages now, off- and on-list, from users that 
> are supporting my efforts as they see the value in making software more 
> useful to users instead of just insisting on adhering to a broken ABI 
> that no one really cares about anymore in the year 2025.
> 

Again, 1990's silicon doesn't care for your 2025 package archive.

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Finn Thain]

On Wed, 18 Jun 2025, Greg Ungerer wrote:

> 
> > It's not really necessary to enforce this on Coldfire. However, since 
> > buildroot builds completely from source, it wouldn't even be a problem 
> > to change the alignment there as well.
> 
> Yes, that is totally right in my experience. Certainly in my ColdFire 
> work it is pretty much always a build-everything approach via buildroot 
> or similar. I wouldn't think an ABI change would actually worry too many 
> ColdFire uses, they don't use distributions like debian on them. (I 
> would love to hear from anyone who does!).
> 

That may work for end-users with a vendor BSP. But upstream developers 
need to be able to swap components. In general, when debugging I often 
have to run old binaries to find out whether I'm dealing with a deeper 
regression or not. Also, there is the bisection problem. It's not just a 
couple of distros who get to pay for an ABI break. It's the entire 
ecosystem.

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Greg Ungerer]

On 19/6/25 08:29, Finn Thain wrote:
> 
> On Wed, 18 Jun 2025, Greg Ungerer wrote:
> 
>>
>>> It's not really necessary to enforce this on Coldfire. However, since
>>> buildroot builds completely from source, it wouldn't even be a problem
>>> to change the alignment there as well.
>>
>> Yes, that is totally right in my experience. Certainly in my ColdFire
>> work it is pretty much always a build-everything approach via buildroot
>> or similar. I wouldn't think an ABI change would actually worry too many
>> ColdFire uses, they don't use distributions like debian on them. (I
>> would love to hear from anyone who does!).
>>
> 
> That may work for end-users with a vendor BSP. But upstream developers
> need to be able to swap components. In general, when debugging I often
> have to run old binaries to find out whether I'm dealing with a deeper
> regression or not. Also, there is the bisection problem. It's not just a
> couple of distros who get to pay for an ABI break. It's the entire
> ecosystem.

I am sure there is value in that for some. Like I said though
that has not been my experience with ColdFire. And by that I mean as
the upstream maintainer of ColdFire Linux support for +20 years.
I pretty mush _always_ build kernel + libs + user for testing even
small kernel changes. My standard small system build takes less
than 1 minute for everything. Again, I am just relating my experience
with this - admittedly probably not typical of actual end users.

FWIW even when I was working on shipping ColdFire based products
my firmware was always a complete update, no separate kernel and
user space updates. Typical of small embedded systems. I can't
actually remember many times I have run with a previously compiled
user space.

Regards
Greg

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Finn Thain]

On Thu, 19 Jun 2025, Greg Ungerer wrote:

> On 19/6/25 08:29, Finn Thain wrote:
> 
> > On Wed, 18 Jun 2025, Greg Ungerer wrote:
> > 
> >>> It's not really necessary to enforce this on Coldfire. However, 
> >>> since buildroot builds completely from source, it wouldn't even be a 
> >>> problem to change the alignment there as well.
> >>
> >> Yes, that is totally right in my experience. Certainly in my ColdFire 
> >> work it is pretty much always a build-everything approach via 
> >> buildroot or similar. I wouldn't think an ABI change would actually 
> >> worry too many ColdFire uses, they don't use distributions like 
> >> debian on them. (I would love to hear from anyone who does!).
> >>
> > 
> > That may work for end-users with a vendor BSP. But upstream developers 
> > need to be able to swap components. In general, when debugging I often 
> > have to run old binaries to find out whether I'm dealing with a deeper 
> > regression or not. Also, there is the bisection problem. It's not just 
> > a couple of distros who get to pay for an ABI break. It's the entire 
> > ecosystem.
> 
> I am sure there is value in that for some. Like I said though that has 
> not been my experience with ColdFire. And by that I mean as the upstream 
> maintainer of ColdFire Linux support for +20 years. I pretty mush 
> _always_ build kernel + libs + user for testing even small kernel 
> changes.

OK, so you're not building binutils, newlib, gcc, gdb etc. with each 
revision. Do you use a board support package (BSP) from the vendor?

> My standard small system build takes less than 1 minute for everything. 
> Again, I am just relating my experience with this - admittedly probably 
> not typical of actual end users.
> 
> FWIW even when I was working on shipping ColdFire based products my 
> firmware was always a complete update, no separate kernel and user space 
> updates. Typical of small embedded systems. I can't actually remember 
> many times I have run with a previously compiled user space.
> 

Given that on-chip RAM is scarce on Coldfire devices, it seems entirely 
plausible that an alignment change could result in ENOMEM after a rebuild 
-- unless the toolchain offered a choice of ABI.

So this becomes a burden for those who maintain tooling that deals with 
ABIs, as well as for the vendor which has to support its BSP -- unless the 
vendor also happens to desire a choice of alignment (that's why I raised 
that question on 6/6).

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Greg Ungerer]

On 19/6/25 15:31, Finn Thain wrote:
> On Thu, 19 Jun 2025, Greg Ungerer wrote:
>> On 19/6/25 08:29, Finn Thain wrote:
>>> On Wed, 18 Jun 2025, Greg Ungerer wrote:
>>>
>>>>> It's not really necessary to enforce this on Coldfire. However,
>>>>> since buildroot builds completely from source, it wouldn't even be a
>>>>> problem to change the alignment there as well.
>>>>
>>>> Yes, that is totally right in my experience. Certainly in my ColdFire
>>>> work it is pretty much always a build-everything approach via
>>>> buildroot or similar. I wouldn't think an ABI change would actually
>>>> worry too many ColdFire uses, they don't use distributions like
>>>> debian on them. (I would love to hear from anyone who does!).
>>>>
>>>
>>> That may work for end-users with a vendor BSP. But upstream developers
>>> need to be able to swap components. In general, when debugging I often
>>> have to run old binaries to find out whether I'm dealing with a deeper
>>> regression or not. Also, there is the bisection problem. It's not just
>>> a couple of distros who get to pay for an ABI break. It's the entire
>>> ecosystem.
>>
>> I am sure there is value in that for some. Like I said though that has
>> not been my experience with ColdFire. And by that I mean as the upstream
>> maintainer of ColdFire Linux support for +20 years. I pretty mush
>> _always_ build kernel + libs + user for testing even small kernel
>> changes.
> 
> OK, so you're not building binutils, newlib, gcc, gdb etc. with each
> revision. Do you use a board support package (BSP) from the vendor?

Vendor?
No vendors involved here. I mostly build for the default in-kernel
configurations, they are whole, do not require any extra external code.
As a maintainer I am only really interested in what is in kernel source.

I build updated toolchains and test on each major/minor release of
binutils, gcc. I do that via my simple-linux scripts
(http://https://github.com/gregungerer/simple-linux). They take a little
longer to run than 1 minute though :-)


>> My standard small system build takes less than 1 minute for everything.
>> Again, I am just relating my experience with this - admittedly probably
>> not typical of actual end users.
>>
>> FWIW even when I was working on shipping ColdFire based products my
>> firmware was always a complete update, no separate kernel and user space
>> updates. Typical of small embedded systems. I can't actually remember
>> many times I have run with a previously compiled user space.
>>
> 
> Given that on-chip RAM is scarce on Coldfire devices, it seems entirely
> plausible that an alignment change could result in ENOMEM after a rebuild
> -- unless the toolchain offered a choice of ABI.

Linux today doesn't really make much use of on-chip RAM on ColdFire.
It is too small to be useful for most things at the kernel scale.
There has been plenty of specialized code to use it over the years to
optimize for some particular application. Not sure how that is relevant
here though.

Granted many ColdFire platforms are short on RAM. Size is a problem.
New versions of packages almost always get larger, that is an on-going
problem. Heck even version to version kernel bloat is a problem.
Especially as the years go on.


> So this becomes a burden for those who maintain tooling that deals with
> ABIs, as well as for the vendor which has to support its BSP -- unless the
> vendor also happens to desire a choice of alignment (that's why I raised
> that question on 6/6).

Changing ABIs will surely affect many. Just keeping up with Linux development
in general is a on-going task, nothing comes fore free.

Regards
Greg

Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Jason Thorpe]

> On Jun 18, 2025, at 10:56 PM, Greg Ungerer <gerg@kernel.org> wrote:
> 
> Granted many ColdFire platforms are short on RAM. Size is a problem.
> New versions of packages almost always get larger, that is an on-going
> problem. Heck even version to version kernel bloat is a problem.
> Especially as the years go on.

As a data point, NetBSD on the sun2 (68010) uses the larger alignment just like there rest of the NetBSD m68k platforms and the typical memory config for those things is 4MB.  ColdFire is not my jam (too new :-), so I’m not really that familiar with the memory configs on those platforms.

-- thorpej

Re: Preliminary results - was: Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Eero Tamminen]

Hi,

On 16.6.2025 18.39, John Paul Adrian Glaubitz wrote:
> To summarize:
> 
> - the ELF header provides provides the e_ident and e_flags fields which could be
>    used for identifying a Linux/m68k system using the 4 bytes alignment ABI
> - MIPS uses e_flags for differentiating its ABIs
> - PA-RISC sets e_ident to 0x03 (Linux) while every other arch uses 0x00 (SysV ABI)
> - qemu-user needs to be patched to deal with the changed alignment (include/user/abitypes.h)
> - the kernel needs to be patched to deal with the changed alignment (arch/m68k/kernel/signal.c)
> - NetBSD uses an emulation layer which allows 2 bytes alignment a.out executables on an
>    ELF system with 4 bytes alignment

So Linux could eventually have similar emulation layer for 2-byte 
aligned ELF binaries (I don't see point in a.out support)?

> - glibc needs to be patched in sysdeps/m68k/utmp-size.h
> - gcc needs to be patched in gcc/config/m68k/linux.h (BIGGEST_ALIGNMENT to 64, EMPTY_FIELD_BOUNDARY
>    and STACK_BOUNDARY to 32, see netbsd-elf.h)
> - the glibc and gcc testsuites should be run in a 4 bytes alignment to check for regressions
> 
> Anything else I'm missing?

- ELF loaders for kernel, its modules and user-space need to be patched 
to reject ELF binaries with wrong ELF flags
- Full test-suites run also for other important projects which e.g. 
include m68k / CF asm code
- Changes tested to work as expected _both_ with 2- and 4-byte alignment 
builds
?


On 18.6.2025 15.27, John Paul Adrian Glaubitz wrote:
 > On Wed, 2025-06-18 at 22:21 +1000, Greg Ungerer wrote:
 >> The bulk of the instruction set is the same. Asm code will look totally
 >> familiar to anyone who knows m68k :-)   One notable difference is that
 >> there is a more limited set addressing modes for some instructions.
 >
 > True, but you won't be able to run any classic m68k binaries on ColdFire
 > and the other way around, are you?

Besides binaries that use just the common instruction subset between 
m68k / CF, the individual m68k instructions can be emulated, or whole 
program can be run under m68k emulation (something more light-weight 
than user-qemu).  See e.g. ACP:
https://en.wikipedia.org/wiki/Atari_Coldfire_Project#Compatibility

It all depends on how much there's value in running older binaries which 
have no sources available, or haven't been rebuild for some other 
reason.  On ACP there was more reason than on Debian...


	- Eero

Re: Preliminary results - was: Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[John Paul Adrian Glaubitz]

Hi,

On Mon, 2025-06-23 at 01:13 +0300, Eero Tamminen wrote:
> On 16.6.2025 18.39, John Paul Adrian Glaubitz wrote:
> > To summarize:
> > 
> > - the ELF header provides provides the e_ident and e_flags fields which could be
> >    used for identifying a Linux/m68k system using the 4 bytes alignment ABI
> > - MIPS uses e_flags for differentiating its ABIs
> > - PA-RISC sets e_ident to 0x03 (Linux) while every other arch uses 0x00 (SysV ABI)
> > - qemu-user needs to be patched to deal with the changed alignment (include/user/abitypes.h)
> > - the kernel needs to be patched to deal with the changed alignment (arch/m68k/kernel/signal.c)
> > - NetBSD uses an emulation layer which allows 2 bytes alignment a.out executables on an
> >    ELF system with 4 bytes alignment
> 
> So Linux could eventually have similar emulation layer for 2-byte 
> aligned ELF binaries (I don't see point in a.out support)?

Not sure why this would be required? I don't expect anyone to download m68k 2 byte binaries
to install and try to run them on a 4 bytes system.

> > - glibc needs to be patched in sysdeps/m68k/utmp-size.h
> > - gcc needs to be patched in gcc/config/m68k/linux.h (BIGGEST_ALIGNMENT to 64, EMPTY_FIELD_BOUNDARY
> >    and STACK_BOUNDARY to 32, see netbsd-elf.h)
> > - the glibc and gcc testsuites should be run in a 4 bytes alignment to check for regressions
> > 
> > Anything else I'm missing?
> 
> - ELF loaders for kernel, its modules and user-space need to be patched 
> to reject ELF binaries with wrong ELF flags

I will check whether the kernel performs any checks on the ELF format on modules.

> - Full test-suites run also for other important projects which e.g. 
> include m68k / CF asm code

As I have already said, I am working on rebuilding the full archive with 4 bytes alignment
and I have already built an initial set of packages without problems. I will set up a local
wanna-build and MiniDAK instance next to automate the rest of the package building.

> - Changes tested to work as expected _both_ with 2- and 4-byte alignment 
> builds

The 2 bytes alignment port will be abandoned in Debian anyway, so I expect to eventually
stop working without me constantly testing it

> On 18.6.2025 15.27, John Paul Adrian Glaubitz wrote:
>  > On Wed, 2025-06-18 at 22:21 +1000, Greg Ungerer wrote:
>  >> The bulk of the instruction set is the same. Asm code will look totally
>  >> familiar to anyone who knows m68k :-)   One notable difference is that
>  >> there is a more limited set addressing modes for some instructions.
>  >
>  > True, but you won't be able to run any classic m68k binaries on ColdFire
>  > and the other way around, are you?
> 
> Besides binaries that use just the common instruction subset between 
> m68k / CF, the individual m68k instructions can be emulated, or whole 
> program can be run under m68k emulation (something more light-weight 
> than user-qemu).  See e.g. ACP:
> https://en.wikipedia.org/wiki/Atari_Coldfire_Project#Compatibility
> 
> It all depends on how much there's value in running older binaries which 
> have no sources available, or haven't been rebuild for some other 
> reason.  On ACP there was more reason than on Debian...

That's my main argument the whole time: There is no value in running old Debian binaries
on m68k as we have the source for everything and can just rebuild packages.

Adrian

-- 
 .''`.  John Paul Adrian Glaubitz
: :' :  Debian Developer
`. `'   Physicist
  `-    GPG: 62FF 8A75 84E0 2956 9546  0006 7426 3B37 F5B5 F913

Re: Preliminary results - was: Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Geert Uytterhoeven]

Hi Eero,

On Mon, 23 Jun 2025 at 00:13, Eero Tamminen <oak@helsinkinet.fi> wrote:
> On 16.6.2025 18.39, John Paul Adrian Glaubitz wrote:
> > To summarize:
> >
> > - the ELF header provides provides the e_ident and e_flags fields which could be
> >    used for identifying a Linux/m68k system using the 4 bytes alignment ABI
> > - MIPS uses e_flags for differentiating its ABIs
> > - PA-RISC sets e_ident to 0x03 (Linux) while every other arch uses 0x00 (SysV ABI)
> > - qemu-user needs to be patched to deal with the changed alignment (include/user/abitypes.h)
> > - the kernel needs to be patched to deal with the changed alignment (arch/m68k/kernel/signal.c)
> > - NetBSD uses an emulation layer which allows 2 bytes alignment a.out executables on an
> >    ELF system with 4 bytes alignment
>
> So Linux could eventually have similar emulation layer for 2-byte
> aligned ELF binaries (I don't see point in a.out support)?

Support for a.out was removed from Linux in commits 19e8b701e258701b
("a.out: Stop building a.out/osf1 support on alpha and m68k") in v5.18
and 987f20a9dcce3989 ("a.out: Remove the a.out implementation") in v6.1.

Gr{oetje,eeting}s,

                        Geert

-- 
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
                                -- Linus Torvalds