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

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:
> >=20
> > - 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 (inc=
lude/user/abitypes.h)
> > - the kernel needs to be patched to deal with the changed alignment (ar=
ch/m68k/kernel/signal.c)
> > - NetBSD uses an emulation layer which allows 2 bytes alignment a.out e=
xecutables on an
> >    ELF system with 4 bytes alignment
>=20
> So Linux could eventually have similar emulation layer for 2-byte=20
> 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
> >=20
> > Anything else I'm missing?
>=20
> - ELF loaders for kernel, its modules and user-space need to be patched=
=20
> to reject ELF binaries with wrong ELF flags

I will check whether the kernel performs any checks on the ELF format on mo=
dules.

> - Full test-suites run also for other important projects which e.g.=20
> 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 wil=
l set up a local
wanna-build and MiniDAK instance next to automate the rest of the package b=
uilding.

> - Changes tested to work as expected _both_ with 2- and 4-byte alignment=
=20
> 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 total=
ly
>  >> familiar to anyone who knows m68k :-)   One notable difference is tha=
t
>  >> 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 ColdFi=
re
>  > and the other way around, are you?
>=20
> Besides binaries that use just the common instruction subset between=20
> m68k / CF, the individual m68k instructions can be emulated, or whole=20
> program can be run under m68k emulation (something more light-weight=20
> than user-qemu).  See e.g. ACP:
> https://en.wikipedia.org/wiki/Atari_Coldfire_Project#Compatibility
>=20
> It all depends on how much there's value in running older binaries which=
=20
> have no sources available, or haven't been rebuild for some other=20
> 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 De=
bian binaries
on m68k as we have the source for everything and can just rebuild packages.

Adrian

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