Hi Andy, On Thu, Nov 8, 2018 at 2:02 AM Andy Shevchenko <andy.shevche...@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.shevche...@gmail.com> wrote: > > > On Fri, Oct 26, 2018 at 3:23 PM Bin Meng <bmeng...@gmail.com> wrote: > > > > On Thu, Oct 25, 2018 at 10:55 PM Bin Meng <bmeng...@gmail.com> wrote: > > > > > On Thu, Oct 11, 2018 at 5:36 PM Andy Shevchenko > > > > > <andriy.shevche...@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 mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
