Gdb Symbol Don't Load

How to prevent GDB from loading debugging symbol for a (large) library?

Is it possible to prevent GDB from loading symbols for these Qt 5 libraries while keeping the debugging symbols for my application?

Yes.

As Richard Critten's comment mentions, setting auto-solib-add to 0 will prevent loading of symbols for all shared libraries, and you can then add files manually with the sharedlibrary command (which accepts a regex). If this regex is omitted, then all shared libraries are loaded.

That however would prevent auto-loading of all symbols (not just debug symbols), and would also prevent auto-loading of symbols for system libraries, which are often required to unwind the stack.

A better approach may be to save a copy of Qt5 libraries with full debug info somewhere, e.g. ~/Qt5-debug/, then run strip -g on the original libraries. That way, you will get symbolic info for all libraries, and in the rare case when you actually need full-debug info for Qt5, you can still do that using the GDB file ~/Qt5-debug/libQt5Core.so.5.2 or similar commands.

The chapter GDB Files from the GDB manual has more documentation on using such separate debugging symbols.

Debugging: my symbols don't get loaded in gdb?

but none of any help (most of these relate to a forgotten -g flag, or an added -s, stripping down the symbols).

It is almost certain that you either have a stray -s somewhere on your link line, or you run stip on the binary during installation.

Look at your link command line and install command carefully, there is strip somewhere in there.

P.S. As Tom Tromey already said, GDB is rarely effective in helping with a problem like this. Using Valgrind or Address Sanitizer will likely get you to the root cause much faster.

Why doesn't the gdb -s option load the symbol file?

It looks like a bug in gdb. gdb sets symarg to the argument that follows -s, but then later in the code, it unconditionally sets symarg to the executable's name. Proposed minimal diff follows:

$ diff -C 1 main.c.orig main.c
*** main.c.orig 2014-07-29 08:37:42.000000000 -0400
--- main.c      2014-09-02 16:27:54.079039046 -0400
***************
*** 864,866 ****
        }
!       symarg = argv[optind];
        execarg = argv[optind];
--- 864,866 ----
        }
!       if (symarg == NULL) symarg = argv[optind];
        execarg = argv[optind];
***************
*** 877,879 ****
        {
!         symarg = argv[optind];
          execarg = argv[optind];
--- 877,879 ----
        {
!         if (symarg == NULL) symarg = argv[optind];
          execarg = argv[optind];

GDB does not load debugging symbols although they are present

Why is this happening and how can I load the debugging symbols?

This is most likely happening because in fact the library does not have debugging symbols.

file binary
... not stripped

Above output does not indicate that the binary has debugging symbols, only that it has a symbol table. So does this: objdump -syms.

To really see debugging symbols, do this: readelf -wi binary (I predict you wouldn't see any).

If debug symbols are in fact present, you should see something like this:

$ readelf -wi ./a.out
Contents of the .debug_info section:

  Compilation Unit @ offset 0x0:
   Length:        0x4e (32-bit)
   Version:       4
   Abbrev Offset: 0x0
   Pointer Size:  8
 <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
    <c>   DW_AT_producer    : (indirect string, offset: 0x5): GNU C11 7.3.0 -mtune=generic -march=x86-64 -g
    <10>   DW_AT_language    : 12   (ANSI C99)
    <11>   DW_AT_name        : t.c
    <15>   DW_AT_comp_dir    : (indirect string, offset: 0x0): /tmp
    <19>   DW_AT_low_pc      : 0x5fa
    <21>   DW_AT_high_pc     : 0xb
    <29>   DW_AT_stmt_list   : 0x0
 <1><2d>: Abbrev Number: 2 (DW_TAG_subprogram)
    <2e>   DW_AT_external    : 1
    <2e>   DW_AT_name        : (indirect string, offset: 0x33): main
    <32>   DW_AT_decl_file   : 1
    <33>   DW_AT_decl_line   : 1
    <34>   DW_AT_type        : <0x4a>
    <38>   DW_AT_low_pc      : 0x5fa
    <40>   DW_AT_high_pc     : 0xb
    <48>   DW_AT_frame_base  : 1 byte block: 9c     (DW_OP_call_frame_cfa)
    <4a>   DW_AT_GNU_all_call_sites: 1
 <1><4a>: Abbrev Number: 3 (DW_TAG_base_type)
    <4b>   DW_AT_byte_size   : 4
    <4c>   DW_AT_encoding    : 5    (signed)
    <4d>   DW_AT_name        : int
 <1><51>: Abbrev Number: 0

GDB symbols work for break and print, but list fails with No debugging symbols found

I have a .elf file with debugging symbols. I can verify this by doing objdump, and seeing a disassembly with the subroutine labels being present.

Debugging symbols are not the same as symbols. For disassembly, you only need the latter. For source listing you need the former.

I can still do things like break main or p/x global_cntr!

These also require only the symbol table.

You can confirm that you don't have debug symbols using objdump -g progmem.elf or readelf -wi progmem.elf.

Your command lines look like debug symbols should be included, but there is no telling what you do with .debug_* sections in your sections.lds linker script. Probably you discard them, which would explain why they aren't there.

Update:

Do you by any chance has an example sections.lds file that has them included?

ld --verbose should print the default linker script. Here is one example.

---

Related Topics