On Tue, Oct 09, 2018 at 07:28:36AM +0800, Bin Meng wrote:
Hi Andy,
On Tue, Oct 9, 2018 at 12:31 AM Andy Shevchenko andriy.shevchenko@linux.intel.com wrote:
On Mon, Oct 08, 2018 at 11:31:32PM +0800, Bin Meng wrote:
+Andy
On Sat, Sep 8, 2018 at 5:00 PM Heinrich Schuchardt xypron.glpk@gmx.de wrote:
make mrproper && make efi-x86_app_defconfig && make
results in
CC common/image.o {standard input}: Assembler messages: {standard input}:21662: Error: junk at end of line, first unrecognized character is `@' {standard input}:21707: Error: junk at end of line, first unrecognized character is `@' {standard input}:21662: Error: can't resolve `end.6878' {.u_boot_list_2_fit_loadable_3 section} - `start.6875' {.u_boot_list_2_fit_loadable_1 section} {standard input}:21707: Error: can't resolve `end.6878' {.u_boot_list_2_fit_loadable_3 section} - `start.6875' {.u_boot_list_2_fit_loadable_1 section}
I am using Debian Buster with gcc-8.2.0.
Building with gcc-7.3.0 works fine.
We had a similar issue for qemu-x86_defconfig in https://lists.denx.de/pipermail/u-boot/2018-July/336393.html which has been resolved.
I can reproduce this with kernel.org GCC 8.1.0 toolchain now. But I have no idea how this error is related to anything. Andy may have some idea.
Does below fixes the issue (check also if the resulting binary runs)?
--- a/arch/x86/config.mk +++ b/arch/x86/config.mk @@ -41,7 +41,7 @@ OBJCOPYFLAGS_EFI := -j .text -j .sdata -j .data -j .dynamic -j .dynsym \ ifeq ($(IS_32BIT),y) CFLAGS_NON_EFI := -mregparm=3 endif -CFLAGS_EFI := -fpic -fshort-wchar +CFLAGS_EFI := -fshort-wchar
Thanks for checking. I tried this but the resulted binary does not boot. Hangs at "U-Boot EFI " and no console output anymore.
That's what I was suspecting after looking how EFI applications are being built.
So, someone familiar with compilers probably needs to check the following and act accordingly: - either new compiler provides new switches to change behaviour as it was in GCC < 8, or - create a small verifiable example with this linked list sections and submit a bug report to GCC, or - U-Boot code (for linked lists) should be reconsidered from new requirements of the compiler, or - EFI U-Boot application should have it's own relocation code (like normal U-Boot does), or - ...anything I missed...
The issue from my limited knowledge looks like this: EFI loader relies on the sections that are natural for dynamically linked libraries (AKA .so), while U-Boot (when runs on bare metal) has another approach, i.e. specific code that does a relocation based only on .reloc information. The linked list sections in U-Boot are meant to be statically compiled, which is not the case for EFI by some reason.
OTOH, it's clearly a compiler behaviour change, since with -fPIC -g it generates DWARF that can't be translated by its own assembler! (See option 2 in above list)