u-boot.git/include/linker_lists.h, branch v2026.07

Merge patch series "A few linker-list fixes"

2026-04-14T17:04:04Z

Simon Glass says: This series includes two patches to fix alignment problems with linker lists. In certain circumstances these can cause the drivers list to be non-contiguous, causing crashes, hangs, etc. Link: https://lore.kernel.org/r/20260321134626.516665-1-sjg@chromium.org

dm: Fix linker list alignment for ll_entry_get()

2026-04-14T17:03:52Z

The extern declaration in ll_entry_get() lacks the __aligned(4) attribute present in ll_entry_declare(). When the compiler sees an unaligned extern reference to a linker list entry in the same compilation unit as its definition, it may increase the section alignment beyond the expected struct size. This causes gaps in the linker list array, which the alignment checker reports as failures. For example, sandbox_dir is both defined and referenced via DM_DRIVER_GET() in sandboxfs.c. The compiler applies 32-byte alignment to its section instead of the 4-byte alignment from the definition, creating an 8-byte gap before it in the driver list. Add __aligned(4) to the extern declaration in ll_entry_get() to match ll_entry_declare() Signed-off-by: Simon Glass

linker_lists: Fix end-marker alignment to prevent padding

2026-04-14T17:03:52Z

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. This makes ll_entry_count() and direct pointer arithmetic work correctly. Fixes: 0b2fa98aa5e5 ("linker_lists: Fix alignment issue") Signed-off-by: Simon Glass

linker_lists.h: drop never used ll_start, ll_end macros

2026-04-03T19:56:32Z

These macros have AFAICT never been used at all. It's also far from clear what purpose it could serve - for one thing, what _type would one pass, other than void perhaps? The example using "struct my_sub_cmd" seems misplaced, as how could one know that the first linker list consists of those, and moreover, how would one know how many there are? The linker list concept is fragile enough on its own, there is no need to have unused functionality lying around that may or may not bitrot and certainly will confuse readers of linker_lists.h. Signed-off-by: Rasmus Villemoes Reviewed-by: Simon Glass

Improve support for linker lists in data structures

2025-01-24T20:34:40Z

A limitation of most linker_list macros is that they cannot easily be used in data structures. This is because they include code inside their expressions. Provide a way to support this, with new ll_start_decl() and ll_end_decl() macros. Signed-off-by: Simon Glass

linker_lists: Rework start/end macros to not rely on undefined behavior

2023-04-04T16:24:29Z

Per the GCC bug listed below, the way we do linker lists is relying on undefined behavior that seems to work in gcc, but doesn't always work in clang. Andrew suggests rewriting our start/end macros in a different way (as implemented here, from what he said in comment 1) to avoid these problems. Reported-by: AdityaK Suggested-by: Andrew Pinski Link: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108915 Signed-off-by: Tom Rini Reviewed-by: Simon Glass Reviewed-by: Andrew Pinski

linker_lists: Rename sections to remove . prefix

2022-06-23T16:58:18Z

Rename the sections used to implement linker lists so they begin with '__u_boot_list' rather than '.u_boot_list'. The double underscore at the start is still distinct from the single underscore used by the symbol names. Having a '.' in the section names conflicts with clang's ASAN instrumentation which tries to add redzones between the linker list elements, causing expected accesses to fail. However, clang doesn't try to add redzones to user sections, which are names with all alphanumeric and underscore characters. Signed-off-by: Andrew Scull Reviewed-by: Simon Glass

treewide: Convert macro and uses of section(foo) to section("foo")

2021-05-24T18:21:30Z

This commit does the same thing as Linux commit 33def8498fdd. Use a more generic form for __section that requires quotes to avoid complications with clang and gcc differences. Remove the quote operator # from compiler_attributes.h __section macro. Convert all unquoted __section(foo) uses to quoted __section("foo"). Also convert __attribute__((section("foo"))) uses to __section("foo") even if the __attribute__ has multiple list entry forms. Signed-off-by: Marek Behún Reviewed-by: Bin Meng Reviewed-by: Simon Glass

linker_lists: document ll_entry_ref parameters

2021-04-10T10:00:24Z

Avoid 'make htmldocs' build warnings: ./include/linker_lists.h:224: warning: Function parameter or member '_type' not described in 'll_entry_ref' ./include/linker_lists.h:224: warning: Function parameter or member '_name' not described in 'll_entry_ref' ./include/linker_lists.h:224: warning: Function parameter or member '_list' not described in 'll_entry_ref' Fixes: 851144350b6f ("linker_lists: Allow use in data structures") Signed-off-by: Heinrich Schuchardt Reviewed-by: Simon Glass

dm: core: Add macros to access the new linker lists

2021-03-22T06:23:28Z

Add macros which work with instantiated devices and uclasses, as created at build time by dtoc. Include variants that can be used in data structures. These are mostly used by dtoc but it is worth documenting them fully for the occasional case where they might come up in user code. Signed-off-by: Simon Glass Signed-off-by: Simon Glass