Re: The road towards LTO: an update and a few question

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)?
_______________________________________________
coreboot mailing list -- [email protected]
To unsubscribe send an email to [email protected]