Hi Rasmus, On Tue, 26 May 2026 at 15:44, Rasmus Villemoes <[email protected]> wrote: > > On Mon, May 25 2026, Simon Glass <[email protected]> wrote: > > > Hi Rasmus, > > > > On 2026-05-22T21:27:48, Rasmus Villemoes <[email protected]> wrote: > >> linker_lists.h: drop _2 from section and symbol name prefix > >> > >> Since commit e2138cf1e60 ("linker_lists.h: drop never used ll_start, > >> ll_end macros"), which removed macros that would create > >> __u_boot_list_1 and __u_boot_list_3 sections, the first _2 in the > >> linker list section names doesn't serve any purpose and is in fact > >> just confusing. So remove it. > >> > >> There never seemed to be a reason for the symbol names to have that > >> _2, other than perhaps for consistency with the section those symbols > >> belonged to. Regardless, remove that as well. > >> > >> All linker scripts use a '__u_boot_list*' glob, so they will work just > >> the same without that common _2. > >> > >> Keep the _2_ part in the separator between list and entry names for > >> symbols, since that is called out in the documentation to allow one to > >> define sublists and iterate over those. I cannot find any current use > >> of that feature, but a later patch will make use of just that. > >> > >> [...] > >> > >> include/linker_lists.h | 8 ++++---- > >> 1 file changed, 4 insertions(+), 4 deletions(-) > > > >> diff --git a/include/linker_lists.h b/include/linker_lists.h > >> @@ -19,11 +19,11 @@ > >> -#define ll_start_section_name(_list) '__u_boot_list_2_'#_list'_1' > >> -#define ll_entry_section_name(_list, _name) > >> '__u_boot_list_2_'#_list'_2_'#_name > >> -#define ll_end_section_name(_list) '__u_boot_list_2_'#_list'_3' > >> +#define ll_start_section_name(_list) '__u_boot_list_'#_list'_1' > >> +#define ll_entry_section_name(_list, _name) > >> '__u_boot_list_'#_list'_2_'#_name > >> +#define ll_end_section_name(_list) '__u_boot_list_'#_list'_3' > > > >> > >> -#define ll_entry_symbol_name(_list, _name) > >> _u_boot_list_2_##_list##_2_##_name > >> +#define ll_entry_symbol_name(_list, _name) > >> _u_boot_list_##_list##_2_##_name > > > > The linker scripts all use a '__u_boot_list*' glob, but several other > > places hard-code the old prefix and this patch does not update them: > > > > scripts/gen_ll_addressable_symbols.sh:14 greps for > > '_u_boot_list_2_[a-zA-Z0-9_]*_2_[a-zA-Z0-9_]*' > > which is fed into the LTO keep-symbols build step (cmd_keep_syms_lto > > in the top-level Makefile). With the new names this matches nothing, > > so LTO builds silently lose the __ADDRESSABLE() guards. > > > > > scripts/event_dump.py hard-codes > > PREFIX_FULL = '_u_boot_list_2_evspy_info_2_' > > PREFIX_SIMPLE = '_u_boot_list_2_evspy_info_simple_2_' > > so the script (and test_event_dump.py) stop finding anything. > > > > test/py/conftest.py has > > RE_UT_TEST_LIST = > > re.compile(r'[^a-zA-Z0-9_]_u_boot_list_2_ut_(.*)_2_(.*)\s*$') > > which is how test.py enumerates ut subtests - this breaks test > > discovery for individual UT suites. > > Ah yes, thanks. I wonder how I could miss those. > > They are of course all trivial to update. But for the > gen_ll_addressable_symbols.sh script, I do wonder why the __ADDRESSABLE > wasn't just made part of the ll macros. It has since grown another > __stack_chk_guard, but that too should be able to just have its > ADDRESSABLE marking in the (ordinary C) TU that defines it.
I'm not really sure, but perhaps it was so that the same mechanism could be used for all such symbols, avoiding __ADDRESSABLE bleeding out into the rest of the code? Regards, Simon
