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

[Harald Seiler]

On Fri, 2021-03-12 at 16:17 +0100, Pali Rohár wrote:
> 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.

For the record, I don't care much, I just noticed the compiler error and
wanted to raise awareness.

But yeah, it might be useful indeed.  I found a blog-post [1] of someone
else doing exactly this, by just adding

  PROVIDE(g_note_build_id = .);
  *(.note.gnu.build-id)

to the linker script and then referencing `g_note_build_id` somewhere to
display it.

But either way I think this only really matters if you have a
hardware-debugger and intend to debug U-Boot with it.

[1]: https://interrupt.memfault.com/blog/gnu-build-id-for-firmware
-- 
Harald