I am using Intel C++ compiler v15.0 on 64-bit Linux, and I have encountered what appears to be a very annoying bug in icpc. Depending on the order in which input files are passed to icpc, the compiler sometimes outputs bad DWARF debug info, which crashes the debugger. I tickled the bug while working with OpenCV 3.0, but someone on Stack Overflow also encountered it and posted a SSCCE. I have further refined the example and attached it as a ZIP file.
Steps to reproduce:
Reading symbols from ./Test_bad.../build/buildd/gdb-7.7.1/gdb/dwarf2read.c:19061: internal-error: follow_die_offset: Assertion `dwarf2_per_objfile->reading_partial_symbols' failed.
Linux Mint 17.1 (based on Ubuntu 14.04), 64-bit
icpc version 15.0.0
gdb-ia version 7.7-8.0.524
gdb version 7.7.1
g++ version 4.8.2
OpenSUSE 12.3 64bit
icpc version 15.0.1
gdb version 7.5.1-2.1.1
gdb version 7.8.1
g++ version 4.7.2
In case it's not obvious from the included Makefile, the only difference between the Test_good and Test_bad binaries is the order in which input files are passed in. ie
icpc -std=c++11 -o Test_bad main.o D.o E.o B.o
icpc -std=c++11 -o Test_good B.o D.o E.o main.o
Interesting coincidence is that I hit this exact same bug today. I discovered that if I used `strip` on the binary first, or compiled without the `-g` option, then I would not get the gdb crash. Of course, debugging without symbols is largely useless. :)
I'm using an older version of icpc (14) so it does not appear that the bug has been fixed in version 15 yet. I used gdb 7.5-1.3.187
I can reproduce this issue with gdb-ia (7.7-8.0.653), but my default gdb works (7.2-56.el6), I assume it may be something related to GDB version too.
I'll submit it to dev team to check more details.
According to the developer, there are no issues in the debug information.
This issue may also be related to GDB (possibly GDB bug). It works with gdb 7.9, could you please try?
Thank you for your confirmation, it is same results as our developer's testing results and it seems to be a GDB bug (older and newer GDB works, only several GDB versions broken).
The issue is now escalated to gdb-ia (GDB provided in Intel Parallel Studio) team.