Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k
On 19/6/25 15:31, Finn Thain wrote:
On Thu, 19 Jun 2025, Greg Ungerer wrote:
On 19/6/25 08:29, Finn Thain wrote:
On Wed, 18 Jun 2025, Greg Ungerer wrote:
It's not really necessary to enforce this on Coldfire. However,
since buildroot builds completely from source, it wouldn't even be a
problem to change the alignment there as well.
Yes, that is totally right in my experience. Certainly in my ColdFire
work it is pretty much always a build-everything approach via
buildroot or similar. I wouldn't think an ABI change would actually
worry too many ColdFire uses, they don't use distributions like
debian on them. (I would love to hear from anyone who does!).
That may work for end-users with a vendor BSP. But upstream developers
need to be able to swap components. In general, when debugging I often
have to run old binaries to find out whether I'm dealing with a deeper
regression or not. Also, there is the bisection problem. It's not just
a couple of distros who get to pay for an ABI break. It's the entire
ecosystem.
I am sure there is value in that for some. Like I said though that has
not been my experience with ColdFire. And by that I mean as the upstream
maintainer of ColdFire Linux support for +20 years. I pretty mush
_always_ build kernel + libs + user for testing even small kernel
changes.
OK, so you're not building binutils, newlib, gcc, gdb etc. with each
revision. Do you use a board support package (BSP) from the vendor?
Vendor?
No vendors involved here. I mostly build for the default in-kernel
configurations, they are whole, do not require any extra external code.
As a maintainer I am only really interested in what is in kernel source.
I build updated toolchains and test on each major/minor release of
binutils, gcc. I do that via my simple-linux scripts
(http://https://github.com/gregungerer/simple-linux). They take a little
longer to run than 1 minute though :-)
My standard small system build takes less than 1 minute for everything.
Again, I am just relating my experience with this - admittedly probably
not typical of actual end users.
FWIW even when I was working on shipping ColdFire based products my
firmware was always a complete update, no separate kernel and user space
updates. Typical of small embedded systems. I can't actually remember
many times I have run with a previously compiled user space.
Given that on-chip RAM is scarce on Coldfire devices, it seems entirely
plausible that an alignment change could result in ENOMEM after a rebuild
-- unless the toolchain offered a choice of ABI.
Linux today doesn't really make much use of on-chip RAM on ColdFire.
It is too small to be useful for most things at the kernel scale.
There has been plenty of specialized code to use it over the years to
optimize for some particular application. Not sure how that is relevant
here though.
Granted many ColdFire platforms are short on RAM. Size is a problem.
New versions of packages almost always get larger, that is an on-going
problem. Heck even version to version kernel bloat is a problem.
Especially as the years go on.
So this becomes a burden for those who maintain tooling that deals with
ABIs, as well as for the vendor which has to support its BSP -- unless the
vendor also happens to desire a choice of alignment (that's why I raised
that question on 6/6).
Changing ABIs will surely affect many. Just keeping up with Linux development
in general is a on-going task, nothing comes fore free.
Regards
Greg
Reply to: