On Mon, Dec 12, 2022 at 02:39:09PM +0100, Max Krummenacher wrote:
Hi Tom
On Thu, Dec 8, 2022 at 9:24 PM Tom Rini trini@konsulko.com wrote:
On Mon, Nov 28, 2022 at 09:41:22AM +0100, Max Krummenacher wrote:
From: Max Krummenacher max.krummenacher@toradex.com
With LTO enabled the U-Boot initial environment is no longer stored in an easy accessible section in env/common.o. I.e. the section name changes from build to build, its content maybe compressed and it is annotated with additional data.
Drop trying to read the initial env with elf tools from the compiler specific object file in favour of adding and using a host tool with the only functionality of printing the initial env to stdout.
See also: https://lore.kernel.org/all/927b122e-1f62-e790-f5ca-30bae4332c77@foss.st.com...
Signed-off-by: Max Krummenacher max.krummenacher@toradex.com Acked-by: Pali Rohár pali@kernel.org Reviewed-by: Simon Glass sjg@chromium.org
Applied to u-boot/next, thanks!
The commit not only fixes the use case on arm64 with LTO enabled, it also fixes sandbox for x86-64. For me on Fedora with a `gcc (GCC) 11.3.1 20220421` both `make sandbox_defconfig; make u-boot-initial-env` and `make sandbox_defconfig; <unselect LTO>; make u-boot-initial-env` fail with
GENENV u-boot-initial-env objcopy: env/common.o: can't dump section '.rodata.default_environment' - it does not exist: file format not recognized sed: can't read u-boot-initial-env: No such file or directoryWouldn't that merit applying the commit to master, i.e. include it in v2023.01?
You can just disable LTO, and it's been an issue for a while now. It's also easy enough to cherry-pick if there's cases out there that can't wait. Thanks again for addressing the problem!