On Fri, 13 Jun 2025 at 12:55, Geert Uytterhoeven <[email protected]> wrote: > > Hi Adrian, > > On Sat, 7 Jun 2025 at 11:44, John Paul Adrian Glaubitz > <[email protected]> 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
