[PATCH 1/2] linker_lists: Fix end-marker alignment to prevent padding

[Tom Rini]

On Mon, Apr 13, 2026 at 11:07:58PM +0200, Rasmus Villemoes wrote:
> On Mon, Mar 23 2026, Simon Glass <sjg at chromium.org> wrote:
> 
> > Hi Rasmus,
> >
> > On Mon, 23 Mar 2026 at 03:56, Rasmus Villemoes <ravi at prevas.dk> wrote:
> >>
> >> On Sat, Mar 21 2026, Simon Glass <sjg at chromium.org> wrote:
> >>
> >> > From: Simon Glass <simon.glass at canonical.com>
> >> >
> >> > Change the alignment of end markers in ll_entry_end() and ll_end_decl()
> >> > from __aligned(4) and __aligned(CONFIG_LINKER_LIST_ALIGN) respectively
> >> > to __aligned(1).
> >> >
> >> > The linker places zero-size end markers at aligned boundaries based on
> >> > what follows them. When the next list's start marker has a high alignment
> >> > requirement (e.g., 32 bytes), padding gets inserted before the end
> >> > marker. This causes the byte span (end - start) to not be an exact
> >> > multiple of the struct size.
> >> >
> >> > The compiler optimises pointer subtraction (end - start) using
> >> > magic-number multiplication for division. This optimisation only produces
> >> > correct results when the byte span is an exact multiple of the struct
> >> > size. With padding, the result is garbage (e.g., -858993444 instead of
> >> > 15).
> >> >
> >> > By using __aligned(1), the end marker is placed immediately after the
> >> > last entry with no padding, ensuring (end - start) equals exactly (n *
> >> > sizeof) where n is the number of entries.
> >>
> >> So I'm wondering why that is guaranteed. I mean, the linker is placing
> >> these sections one after another in order
> >>
> >>
> >>   2_foo_2_last_foo   size sizeof(struct foo), alignment max(4, alignof(struct foo))
> >>   2_foo_3            size 0, alignment 4 (1 with your patch)
> >>   2_bar_1            size 0, alignment CONFIG_LINKER_LIST_ALIGN
> >>   2_bar_2_first_bar  size sizeof(struct bar), alignment max(4, alignof(struct bar))
> >>
> >> So clearly the end of last_foo does have 4-byte alignment, yet it is
> >> observed that the linker sometimes makes 2_foo_3's address coincide with
> >> 2_bar_1's address?
> >>
> >> What I don't understand is that it seems that the linker could place the
> >> zero-size object 2_foo_3 at any 4-byte aligned address between the end
> >> of 2_foo_2_last_foo and 2_bar_1. And the same seems to be true when one
> >> changes it to have even smaller alignment requirement.
> >>
> >> So why does an align(1) stop the linker from placing that 0-size section
> >> at the same address as 2_bar_1, or even force it (as we need) to put it
> >> at the first possible address, i.e. immediately after last_foo?
> >
> > My commit message was a bit confusing - alignment of symbol is not
> > based on what follows an item, just on the item itself (despite
> > appearances to the contrary).
> >
> > My understanding of this is that the linker processes input sections
> > sequentially within the SORT(_u_boot_list*) output section, placing
> > each at the first address that satisfies its alignment. So the
> > location counter advances forward only by the minimum needed. But this
> > isn't specific to alignment 1.
> >
> > I've used __aligned(1) in order to make it clear we don't want any
> > alignment. In all current cases, __aligned(4) would be OK too since
> > the structs we use are always 4-byte-aligned. We just want the end
> > marker to go at the current location-counter, i.e. immediately after
> > the last entry. I suppose another way of saying this is that we want
> > the end marker to be a 'multiple of the struct size' higher than the
> > start marker.
> >
> > With ll_end_decl() using __aligned(CONFIG_LINKER_LIST_ALIGN), the
> > result depends on the struct size and the number of items in the list.
> > On sandbox the value is 32. If the last entry ends at, say, 0x103c
> > (4-byte aligned but not 32-byte aligned), the linker must advance to
> > 0x1040 to place the end marker. So then there is a 4-byte gap, i.e.
> > (end - start) not a multiple of sizeof(struct), and the compiler's
> > magic-number division optimisation fails.
> 
> OK, yes, I agree that the proper thing to use for the end markers is
> aligned(1). But I can't help but feel that this problem is somewhat
> self-inflicted; I still don't understand the rationale for
> CONFIG_LINKER_LIST_ALIGN, even if I've read 0b2fa98aa5 multiple
> times.
> 
> The ELF format includes an alignment field for sections, so if gcc emits
> a symbol to some section which requires 16 byte alignment, that section
> should get an alignment requirement of 16 bytes. So I guess what I don't
> understand is how gcc can end up emitting a section containing a "struct
> driver" in one TU with an alignment of 16 bytes, while another TU
> contains a section with a "struct driver" that only requires 8 byte
> alignment.
> 
> So yes, this commit improves things, and you can take my Ack, but I'd
> like to have some very concrete examples of a set of complete TUs (not
> just single lines) and compiler invocations that exhibit some of the
> problems that this is all about. Because I'd really like to look at the
> intermediate .o files and see what's going on.

Agreeing it would be very good to better understand things, after
applying this series I see:
            qemu-arm-sbsa  : rodata -8 text +8
               u-boot: add: 0/0, grow: 2/0 bytes: 8/0 (8)
                 function                                   old     new   delta
                 gic_v3_its_get_gic_addr                    200     204      +4
                 acpi_fill_iort                             264     268      +4


Which is because of patch 2 in the series. There are a few other
examples of gic_lpi_tables_init changing on say
ls1028ardb_tfa_SECURE_BOOT from the same commit.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 228 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20260414/63c87d7a/attachment.sig>