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? > 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. 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).
