Hi Marek, On Fri, 2021-03-12 at 11:33 +0100, Marek Behún wrote: > Hello, > > I am sending version 2 of patches adding support for LTO to U-Boot. > > This series was tested by Github/Azure CI at > https://github.com/u-boot/u-boot/pull/57 > > Code reduction is on average 4.23% for u-boot.bin and 13.58% for > u-boot-spl.bin. > > I am currently running a build test for all 1077 ARM defconfigs. > Of the first 232 defconfigs, 2 are failing when LTO is enabled > (chromebook_jerry and chromebook_speedy). Note that this series > only enables LTO for tested boards. > > Changes since v1: > - remove patches applied into u-boot-marvell > - added Reviewed-by tags > - addressed some issues discovered by Bin Meng, Marek Vasut, > Heinrich Schuchardt > - added more ARM boards (thanks to Adam Ford, Tim Harvey and Bin Meng) > - removed --gc-sections for ARM if internal libgcc is used > - remove -fwhole-program in final LTO LDFLAGS > - declared all 4 functions (memcpy, memset, memcmp, memmove) __used, > (these are mentioned in GCC man page for option -nodefaultlibs that > the compiler may generate; this seems to be a bug in GCC that linking > fails with LTO even if these functions are present, because the > symbols can be renamed on some targets by optimization)
I'm hitting a compiler error when building with imx6q_logic_defconfig: real-ld: error: no memory region specified for loadable section `.note.gnu.build-id' It seems this is caused by calling the linker through a gcc invocation which adds a `--build-id` commandline flag. I think the linker script which is used for SPL in this case (arch/arm/mach-omap2/u-boot-spl.lds) isn't properly set up to deal with a build-id. I'm not sure how to deal with this. One could either add `--build-id=none` to the GCC commandline to suppress generation of this section entirely (it is not emitted in non-LTO builds right now anyway) or include it in .text in said linker script so it is visible on the target. What do you think? I should note that I am using a Yocto-generated toolchain. I suppose most standard toolchains' behavior regarding the `--build-id` flag probably differs. Regards, -- Harald
