Hi Arthur,
First of all, thanks a lot for putting all this work into getting LTO working. The benefits really seem promising!
Do you have a rough list of the types of things that the LLD linker cannot deal with (e.g. there seems to be something about not using a symbol before it was defined, like with BOOTBLOCK_TOP, but then it doesn't seem to apply everywhere, e.g. for ID_SECTION it still seems to work?), so we can get an idea what kind of limitations we'd be accepting here for both current and future linker scripting? I wouldn't mind some rewrites to the x86 bootblock script in general, since some of it honestly seems unnecessarily convoluted anyway, but it's more concerning if you need to drop features (like commenting out all of those asserts at the end) when there's no way to make something similar work with LLD.
Also, are you sure that all the Arm boards are fine? Did you do a full abuild and then also compare the images (with BUILD_TIMELESS) to make sure the layouts didn't actually shift? We do a bunch of complicated things in our linker scripts, I'm actually surprised that LLD would be fine with everything besides the x86 bootblock (it didn't use to be at all a couple of years ago, but I guess they may have improved it).
I think the other big question here is: why do we care about clang at all? If GCC can do LTO with BFD, why don't we just stick with that? My understanding was that people just added clang support to coreboot "for fun" to see if it was possible, and we said okay as long as you can do it without having to break any code. But now if we do need to make meaningful code changes to support it, should we reexamine why we want it at all? Is anyone actually using it in a production use case (and if so, why)?