Why does gdb-7.4 does not show source-info on binaries generated with recent compilers?

Question

I'm on Ubuntu 12.04 with gdb 7.4 and gcc-4.6 and gcc-4.8

When building this simple program

#include <stdio.h>

int main(void)
{
    printf("hello world\n");
    return 0;
}

with gcc-4.6 and then extracting debug-sections with objdump -W I see a section called .debug_loc . Not so with gcc-4.8 or later. Not luck either with clang-3.6 or later.

The version of gdb on my system (7.4) seems to require this section to be able to associate source and execution.

The same problem appears when using the thread-sanitizer with clang. It is not able to associate source-lines with callstacks.

Why is there no more debug_loc-section and/or why is gdb 7.4 incapable of handling binaries missing this section? (GDB 7.7 works fine on the same binary) Is there a way to fix this with compiler flags?

Answer 1

The .debug_loc section does not match addresses to program source lines, this is the job of the .debug_line section.

The .debug_loc section contains location lists, that is the location at which a variable lives. If a variable lives in many places during its lifetime then a location list is required, this location list is placed in the .debug_loc section. If a variable lives in just one place then the location expression can be placed inline in to the .debug_info section. Clearly if no location lists are required then the .debug_loc section can be removed completely. On your simple program with no variables I'm a little surprised that there was ever a .debug_loc section, without seeing the full debug I don't know what it was being used for. I'm not really surprised that a later (better) compiler has managed to remove the use of the .debug_loc section.

As for why older versions of gdb are struggling while newer versions handle your binary, I would guess that this is some newer DWARF construct (DWARF being the debug format). Or if not a newer construct maybe just a construct that was never seen before, and so not supported in older versions of gdb. Without access to the specific binary it's hard to know.

As a general rule, always use the most up to date version of gdb that you have access to in order to get support for the widest range of DWARF constructs.