[U-Boot] [BUG] efi-x86_app_defconfig does not build with gcc 8.2

[Bin Meng]

Hi,

On Thu, Oct 25, 2018 at 10:55 PM Bin Meng <bmeng.cn at gmail.com> wrote:
>
> Hi Andy,
>
> On Thu, Oct 11, 2018 at 5:36 PM Andy Shevchenko
> <andriy.shevchenko at 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.shevchenko at 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 at 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