Failed assertion "Cannot export BSS symbol" with ld.lld

[nathanchance]

Commit 90530521079e ("arm64/boot: Disallow BSS exports to startup code") in the arm64 tree (by @ardbiesheuvel) adds an ASSERT to the linker script to try and catch places where variables in .bss are used before .bss has actually been initialized. This assertions gets triggered in certain configurations; for example, allyesconfig fails with:

$ make -skj"$(nproc)" ARCH=arm64 LLVM=1 clean allyesconfig vmlinux
ld.lld: error: Cannot export BSS symbol _ctype to startup code
ld.lld: error: Cannot export BSS symbol swapper_pg_dir to startup code
ld.lld: error: Cannot export BSS symbol _etext to startup code
ld.lld: error: Cannot export BSS symbol __start_rodata to startup code
ld.lld: error: Cannot export BSS symbol __inittext_begin to startup code
ld.lld: error: Cannot export BSS symbol __inittext_end to startup code
ld.lld: error: Cannot export BSS symbol __initdata_begin to startup code
...

@arndb had a few randconfigs that hit this as well.

There does not appear to be an easy way to see what values these symbols have during linking to figure out why the assertion is failing. @MaskRay do you have any suggestions for how to debug something like this?

[MaskRay]

Linkers use a fixed-point iteration to compute section and symbol addresses. It seems that GNU ld only reports ASSERT failure for the last iteration. LLD did not do this, which I have just fixed in 5859863bab7fb1cd98b6028293cba6ba25f7d514 (similar to previous fixes I've made).

---

For users unfamiliar with LLD, debugging can be complex... Setting a breakpoint at e().getValue() allows inspection of how the std::function e() is evaluated, though the process may be intricate.

[nathanchance]

https://git.kernel.org/arm64/c/e21560b7d33c4f692cc9cd5b75ff09024f5a69d2