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 <[email protected]> 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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

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

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)