[PATCH u-boot v2 00/38] U-Boot LTO (Sandbox + Some ARM boards)

[Pali Rohár]

On Friday 12 March 2021 16:07:22 Harald Seiler wrote:
> On Fri, 2021-03-12 at 15:26 +0100, Marek Behun wrote:
> > On Fri, 12 Mar 2021 15:21:05 +0100
> > Harald Seiler <hws at denx.de> wrote:
> > 
> > > 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,
> > 
> > I encountered this with Debian's cross toolchain, but since this did
> > not happen on my station with Gentoo crossdev toolchain, nor on Azure
> > CI, I ignored it.
> > 
> > What is the purpose of --build-id? Why do people use it?
> 
> I'm not entirely sure but I think it acts as a unique identifier for
> a certain binary.  So you can match up a core-dump with its debug info for
> example.
> 
> But I am unsure if anyone in the firmware space is actively using this
> feature... At least U-Boot does not actually include the build-id on the
> target - it is not generated for SPL at all and U-Boot proper only
> contains it in the ELF file, it is not exported into the raw binary.

IIRC Debian is using build id to split out debug symbols to external ELF
binary. So based on build id it can correctly identify which external
ELF file contains correct debug symbols for stripped ELF binary. IIRC
gdb in Debian can locale external ELF file with debug symbols from
well-known location, so you just need to install appropriate -dbg
package and gdb automatically loads debug symbols.

But if you want to use build id for any purpose, you need some binary
"container" where you can store metadata (EXE, ELF, ...). So I think
build id would be normally stripped from RAW u-boot.bin binary.

But if you really want to use build id in U-Boot, what about following
idea? Put build id into some U-Boot global variable and add some U-Boot
command which can print it in U-Boot console. And then based on it you
can locale u-boot ELF binary on your disk (if you have not removed it)
and you can start e.g. debugging or other things.

In this case build id can be useful for unique identification of the
built binary.