[U-Boot] [BUG] efi-x86_app_defconfig does not build with gcc 8.2
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
+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
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
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
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)
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
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
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!
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
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.
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
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...
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
participants (4)
-
Andy Shevchenko -
Andy Shevchenko -
Bin Meng -
Heinrich Schuchardt