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!