Re: Question on BIGGEST_ALIGNMENT in GCC on NetBSD/m68k

[Greg Ungerer <gerg@kernel.org>]

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