CODEWITHSUNDEEP
gdbdwarf
Dror Harari
Dror Harari

Reputation: 3287

Dwarf Error: wrong version in compilation unit header (is 4, should be 2)

A shared object was built on RedHat Linux and while all the code was compiled with debug, the debugger (gdb) refused to load the symbols and issued an error as in:

...
GNU gdb   Fedora (6.8-37.el5) 
...
This GDB was configured as "x86_64-redhat-linux-gnu"...
Dwarf Error: wrong version in compilation unit header (is 4, should be 2) [in module libgrokf.so]

With this error, I could not get break points to trigger in any function nor see proper stack trace. I recompiled the entire project but nothing helped. I do know that some time in the past there was no problem in debugging that module.

What is causing this problem?

Upvotes: 29

Views: 45852

Answers (5)

Mustafa Ergül
Mustafa Ergül

Reputation: 41

FOR STM32CUBE IDE To ensure all compilation units use the same DWARF version, you need to specify your desired DWARF version in the compiler options of your compiler settings. DWARF is primarily a debugging format used in compiling and debugging programs. The method for doing this is shown in the following 3 screenshots.

enter image description here

enter image description here

enter image description here

Upvotes: 0

normal_max
normal_max

Reputation: 11

I had the same error. On OpenBSD GDB version from repository is 6.3 but current is 14.2. It is have not been updated because of license conflicts for years, and should not be used. Should not be in repository probably.

Solution is to compile GDB from source, ports, or use lldb debugger. It works with programs compiled with clang and with gcc.

Upvotes: 0

Marco
Marco

Reputation: 2897

The problem is that your version of gdb doesn't support the DWARF version used in one of your binaries.

The solution: Update gdb or compile your files using another debug format (DWARF2 works on gdb 6).

I have recently had this problem with freeBSD and nasm, nasm compiling binaries with DWARF3 and the gdb that ships with freeBSD 9.1 doesn't accept it.

I hope this answer helps anyone having a similar problem :P

Debug options for GCC

Upvotes: 18

Kapil Satija
Kapil Satija

Reputation: 33

My issue got resolved by choosing the right gdb version for debugging. Earlier I was using the gdb 7.0... and when I started using the gdb version 7.10, i was able to debug my application.

Upvotes: 3

Dror Harari
Dror Harari

Reputation: 3287

As it happens, the module that could not debug was mostly built from sources except for one little 'external' object file someextcode.o that was provided by a 3rd party.

In investigating the problem it was found that the someextcode.c was compiled with the -g3 flag which, apparently, places DWARF version of 4 in the compilation unit header. Changing that to -g resolved the problem.

Unfortunately, it appears a problem with a single module can break the debug-ability of an entire shared object (.so) without giving a clear indication of root of the problem.

Upvotes: 18

Related Questions