Hi Marek,
On Thu, 15 Jan 2026 at 02:02, Marek Vasut <[email protected]> wrote: > > On 1/14/26 3:17 PM, Tom Rini wrote: > > Hello Tom, > > >>> OK. And why can't we make that check at $sym rounded up, and ensure our > >>> build targets pad? Going back to the commit message here, it's easy to > >>> tell the linker to place $sym at the right spot, but it's hard to make > >>> sure the output is padded. So having typed all that, maybe we need to > >>> do: > >>> d) Update linker scripts to ALIGN(8) the above symbols and have the make > >>> targets use dd to ensure padding prior to concatenation > >>> ? > >> d) looks like what we should do, yes > > > > Poking at this harder, I'm not actually sure we need to use dd at all, > > but we do need to fix our linker scripts, and then going back to when > > Ilias reworked and cleaned up a bunch of them, get the changes reviewed > > by the toolchain experts he got ahold of :) > > I wonder if LD can always guarantee trailing alignment of the binary. If > it can, then yes, dd would only be obscuring alignment problems and > trailing DT look up failures which are hard to debug. It would be nice > to drop the dd part, but I am not sure if we are able to do it reliably. LD won't pad align anything that doesn't have code afterwards. IOW inserting an . = ALIGN(8); just before the .end symbol won't guarantee alignement unless there's a section/code following. What you can do is add an ALIGN(8) inside the last section. That will guarantee that the last symbol is aligned. There's also the SUBALIGN command which messes around with the input section alignment -- that normally is automatically calculated, but Tom tested it yesterday without success. I'll have a closer look to the linker script in case I can come up with something more elegant. Which defconfig should I use to reproduce the issue? Cheers /Ilias
