Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k
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
Reply to: