Hi Arthur,
this sounds very interesting.
On 23.02.24 17:47, Arthur Heymans wrote:
So my question would be, whether we want to support non BFD linkers and therefore not support all the magic in linker scripts we currently have.
Did you find out any particular (magic) construct we are currently using that fails? Or is it the overall complexity of the script?
I was already wondering lately if we shouldn't split the complex x86 linker script for different use cases (e.g. native, FSP, etc.). If we had three scripts instead of one, we would sometimes have to make the same change in multiple files. But, OTOH, I don't think we touch the linker scripts that much. And every time I look into the x86 one, it seems hard to find top and bottom.
If non BFD linkers are acceptable, how do you propose we deal with it? When not using LTO you could in principle use a different linker of your choosing. Should we just move to lld to make sure CI is happy about linker scripts? Should it be an option, but then we won?t have CI being able to test it except on a few boards put in configs/ ? Maybe have both, but then change the default once LLD is known to work well enough? Sidenote: LLD is faster than BFD but linking is not an expensive step in coreboot anyway.
I wouldn't mind switching to LLD. Would prefer that we focus on a single linker, though. There is some soothing feeling when one knows that everybody is using the same toolchain, and chances that bugs are discovered early are higher.
Btw. can clang+lld with LTO still link against GCC objects, e.g. libgfxinit?
Nico