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

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

[Heinrich Schuchardt]

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.

Best regards

Heinrich Schuchardt

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

[Bin Meng]

+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.

Regards,
Bin

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

[Andy Shevchenko]

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


-- 
With Best Regards,
Andy Shevchenko

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

[Bin Meng]

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.

Regards,
Bin

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

[Andy Shevchenko]

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)

-- 
With Best Regards,
Andy Shevchenko

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

[Bin Meng]

Hi Andy,

On Thu, Oct 11, 2018 at 5:36 PM Andy Shevchenko
<andriy.shevchenko@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@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)
>

Thank you for these useful suggestions! I will see if I can create a
small test program to trigger this issue.

Regards,
Bin

[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@gmail.com> wrote:
>
> Hi Andy,
>
> On Thu, Oct 11, 2018 at 5:36 PM Andy Shevchenko
> <andriy.shevchenko@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@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)
> >
>
> 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] [BUG] efi-x86_app_defconfig does not build with gcc 8.2

[Andy Shevchenko]

On Fri, Oct 26, 2018 at 3:23 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> On Thu, Oct 25, 2018 at 10:55 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > On Thu, Oct 11, 2018 at 5:36 PM Andy Shevchenko
> > <andriy.shevchenko@linux.intel.com> wrote:

> > > 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.

Cool! Please, share the bug link whenever it will be filled, thanks!

-- 
With Best Regards,
Andy Shevchenko

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

[Bin Meng]

Hi Andy,

On Fri, Oct 26, 2018 at 8:41 PM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Fri, Oct 26, 2018 at 3:23 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > On Thu, Oct 25, 2018 at 10:55 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > On Thu, Oct 11, 2018 at 5:36 PM Andy Shevchenko
> > > <andriy.shevchenko@linux.intel.com> wrote:
>
> > > > 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.
>
> Cool! Please, share the bug link whenever it will be filled, thanks!
>

Sure, though waited for some time to get my GCC Bugzilla created by the admin ..

Here it is: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87793

Regards,
Bin

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

[Andy Shevchenko]

On Mon, Oct 29, 2018 at 10:41:29PM +0800, Bin Meng wrote:
> On Fri, Oct 26, 2018 at 8:41 PM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Fri, Oct 26, 2018 at 3:23 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > On Thu, Oct 25, 2018 at 10:55 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > On Thu, Oct 11, 2018 at 5:36 PM Andy Shevchenko
> > > > <andriy.shevchenko@linux.intel.com> wrote:
> >
> > > > > 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.
> >
> > Cool! Please, share the bug link whenever it will be filled, thanks!
> >
> 
> Sure, though waited for some time to get my GCC Bugzilla created by the admin ..
> 
> Here it is: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87793

Thanks!
It seems compiler bug has been confirmed!

P.S. Btw, I recommend to read a commit message to a proposed fix.

-- 
With Best Regards,
Andy Shevchenko

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

[Bin Meng]

Hi Andy,

On Thu, Nov 8, 2018 at 2:02 AM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Mon, Oct 29, 2018 at 10:41:29PM +0800, Bin Meng wrote:
> > On Fri, Oct 26, 2018 at 8:41 PM Andy Shevchenko
> > <andy.shevchenko@gmail.com> wrote:
> > > On Fri, Oct 26, 2018 at 3:23 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > On Thu, Oct 25, 2018 at 10:55 PM Bin Meng <bmeng.cn@gmail.com> wrote:
> > > > > On Thu, Oct 11, 2018 at 5:36 PM Andy Shevchenko
> > > > > <andriy.shevchenko@linux.intel.com> wrote:
> > >
> > > > > > 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.
> > >
> > > Cool! Please, share the bug link whenever it will be filled, thanks!
> > >
> >
> > Sure, though waited for some time to get my GCC Bugzilla created by the admin ..
> >
> > Here it is: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87793
>
> Thanks!
> It seems compiler bug has been confirmed!
>

Yes, the bug is marked as a regression and a patch has been proposed.

> P.S. Btw, I recommend to read a commit message to a proposed fix.

Good idea. However I read the fix commit message and have no idea on
how to workaround in the U-Boot codes. Do you have any idea?

Regards,
Bin

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

[Andy Shevchenko]

On Thu, Nov 8, 2018 at 2:28 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> On Thu, Nov 8, 2018 at 2:02 AM Andy Shevchenko
> <andy.shevchenko@gmail.com> wrote:
> > On Mon, Oct 29, 2018 at 10:41:29PM +0800, Bin Meng wrote:

> > > Here it is: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87793

> > P.S. Btw, I recommend to read a commit message to a proposed fix.
>
> Good idea. However I read the fix commit message and have no idea on
> how to workaround in the U-Boot codes. Do you have any idea?

There is no workaround, just interesting reading in my opinion.
He explains what happened there and what he did to mitigate it.

Basically for now it means U-Boot can't be built with gcc 8.x for x86.
Of course, if you have time to try the patch and build a compiler, and try it...


-- 
With Best Regards,
Andy Shevchenko

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

[Bin Meng]

On Thu, Nov 8, 2018 at 8:47 AM Andy Shevchenko
<andy.shevchenko@gmail.com> wrote:
>
> On Thu, Nov 8, 2018 at 2:28 AM Bin Meng <bmeng.cn@gmail.com> wrote:
> > On Thu, Nov 8, 2018 at 2:02 AM Andy Shevchenko
> > <andy.shevchenko@gmail.com> wrote:
> > > On Mon, Oct 29, 2018 at 10:41:29PM +0800, Bin Meng wrote:
>
> > > > Here it is: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87793
>
> > > P.S. Btw, I recommend to read a commit message to a proposed fix.
> >
> > Good idea. However I read the fix commit message and have no idea on
> > how to workaround in the U-Boot codes. Do you have any idea?
>
> There is no workaround, just interesting reading in my opinion.
> He explains what happened there and what he did to mitigate it.
>
> Basically for now it means U-Boot can't be built with gcc 8.x for x86.
> Of course, if you have time to try the patch and build a compiler, and try it...
>

A small correction, it's only the efi-x86_app can't be built with gcc
8.x/9.x for x86, not all x86 targets :)

+Simon,

Simon, maybe we can enhance buildman to specify the GCC toolchain
version for a specific target?

Regards,
Bin