From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tom Rini Date: Fri, 12 Mar 2021 10:33:02 -0500 Subject: [PATCH u-boot v2 00/38] U-Boot LTO (Sandbox + Some ARM boards) In-Reply-To: References: <20210312103429.25895-1-marek.behun@nic.cz> <90b26f9274f50c1ac1f07cbec14efc76be120aca.camel@denx.de> <20210312152606.60e41cb4@nic.cz> <20210312151704.cgk5xzpag6epj67i@pali> Message-ID: <20210312153302.GZ1310@bill-the-cat> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On Fri, Mar 12, 2021 at 04:26:54PM +0100, Harald Seiler wrote: > 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 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. It looks like in Linux they do --build-id=sha1 and then use it in panic messages, from a quick skim. For the LTO series, a work-around of --build-id=none is probably fine, but it would be good to work putting the ID in to some existing and relevant would be good. Perhaps just the "version" command ? -- Tom -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 659 bytes Desc: not available URL: