Hi, On Thu, Oct 25, 2018 at 10:55 PM Bin Meng <bmeng...@gmail.com> wrote: > > Hi Andy, > > On Thu, Oct 11, 2018 at 5:36 PM Andy Shevchenko > <andriy.shevche...@linux.intel.com> wrote: > > > > 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.shevche...@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.g...@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) > > > > Thank you for these useful suggestions! I will see if I can create a > small test program to trigger this issue. >
I created a small test case to trigger this issue. A workaround is to disable '-Os' so that the test case pass. Of course disabling '-fpic' also works. To me this looks like a bug when compiling pic codes with optimization on. I will submit a bug report go GCC. Regards, Bin _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot