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