4

I'm trying to debug a code using GDB in a Fedora machine. It produces this message each time I run it.

Missing separate debuginfos, use: debuginfo-install glibc-2.18-12.fc20.x86_64 libgcc-4.8.3-1.fc20.x86_64 libstdc++-4.8.3-1.fc20.x86_64

My questions:

  1. Should these packages be in GDB by default?
  2. What is the function of each of these packages?
  3. In real production environments should these packages be installed for GDB?
  4. Is it ok if I do not install these packages? What will be the effect?

2 Answers 2

6
  1. No. gdb is packaged by a maintainer, glibc is packaged by another maintainer, gcc, libstdc and so on all all packaged by different maintainers. To package the debuginfo for these along with gdb would take considerable coordination. Each time one of the packages changed, the gdb maintainer would have to repackage and release. It would become quite cumbersome to manage. gdb can also debug other languages, for example java, which wouldn't need the debuginfo for the libraries listed.

  2. The debuginfo packages contain the source code and symbols stripped from the executable. They are only required during debugging, therefore are redundant during normal use. They do take up a fair amount of space, therefore are stripped during production releases.

  3. It depends. Most C code will use glibc etc. However, if you're debugging package X and don't need to delve into the internals of glibc you could manage without installing it. If you want to follow the code in gdb all the way to the low-level glibc, or if you think there's a bug in the library itself, then you'll need to install it. On the other hand, some C code might be statically linked and should have everything needed within it's own debuginfo package, or an application could be written in another language. Neither would need these installed.

  4. Yes. The effect of not installing these packages is that you will not be able to debug effectively into the routines provided by them. As in 3 above, it all depends on whether you need to debug at that level or not.

Note: You'll find that many applications have been optimised (with the -O flag in the compiler) and don't debug that well with debuginfo. A workaround is to recompile without any optimisation.

0

My solution might be helpful to those whom have this warning.

  1. They are packaged into different packages in fedora. The command dnf install debuginfo-install packagename can solve this warning.

My os is fedora 29 workstation x86_64. Debuginfo packages can be find in archive repo, for example glibc-debuginfo-2.28-9.fc29.x86_64.rpm, glibc-debuginfo-common-2.28-9.fc29.x86_64.rpm, libgcc-debuginfo-8.2.1-2.fc29.x86_64.rpm, libstdc++-debuginfo-8.2.1-2.fc29.x86_64.rpm.

Package for other editions just checks here, the archive editions or the latest editions.

source code: gcc-mirror online on github, glibc online on sourceware, libstdc++ in gcc online source code. The source packages including gcc, gdb, glibc on https://ftp.gnu.org/gnu/

  1. See Why gdb is showing message "Missing separate debuginfos"?

To debug any application need it source code and debugging symbols installed on the system to get more information with respect to individual frames in the stack.

So debuginfo packages of all the dependencies of the binary trying to debug need to be installed.

The debuginfo packages including .debug files and source files. After installed those packages, .debug files will be stored in /usr/lib/debug/lib64/ and source files in /usr/src/debug/ for fedora 29. And a link .gnu_debuglink section will be added to glibc library file.

For example, /usr/lib/debug/lib64/libc-2.28.so.debug is installed from glibc-debuginfo-2.28-39.fc29.x86_64.

[user@localhost myctest]$ rpm --query --list glibc-debuginfo-2.28-39.fc29.x86_64 | grep libc-2.28.so.debug
/usr/lib/debug/lib64/libc-2.28.so.debug
[user@localhost myctest]$ readelf -S /usr/lib64/libc-2.28.so | grep debug
  [73] .gnu_debuglink    PROGBITS         0000000000000000  002a6df0
[user@localhost myctest]$ readelf -S /lib64/libc-2.28.so | grep debug
  [73] .gnu_debuglink    PROGBITS         0000000000000000  002a6df0
[user@localhost myctest]$ readelf --debug-dump=links /usr/lib64/libc-2.28.so 
Contents of the .gnu_debuglink section:

  Separate debug info file: libc-2.28.so.debug
  CRC value: 0x9bd5ece3

and source files:

[user@localhost myctest]$ ls -l /usr/src/debug/
total 4
drwxr-xr-x. 60 root root 4096 Aug 10 18:36 glibc-2.28-110-g57922433fa

The script that generates those packages is /usr/lib/rpm/find-debuginfo.sh.

You can make your own .debug file manually.

Try an example:

#include <stdio.h> 

int main (int argc, char *argv[]) { 

    int n; 
    for (n=0; n<10; n++) { 
       printf("Print Number: %d\n", n); 
    } 
    return 0; 
} 

compile as debug edition executable file

gcc example.c -o example.bin -g

create .debug file and remove debug section from example.bin file.

objcopy --only-keep-debug example.bin example.debug
strip -g example.bin

Connect them together. Add .gnu_debuglink to example.bin.

objcopy --add-gnu-debuglink=example.bin.debug example.bin

Then you have:

[user@localhost myctest]$ readelf --debug-dump example.bin 
Contents of the .gnu_debuglink section:

  Separate debug info file: example.bin.debug
  CRC value: 0xefae614e

  1. In my fedora workstation x86_64 release edition, these debug packages are not installed by default. I don't think the debug files should be installed in the production environment.

  2. It is for StackTraces.

stack trace should look like:

Reading symbols from example.bin...done.
(gdb) start
Temporary breakpoint 1 at 0x401135: file example.c, line 6.
Starting program: /home/codc/works/cpp/example.bin 
warning: Loadable section ".note.gnu.property" outside of ELF segments

Temporary breakpoint 1, main (argc=1, argv=0x7fffffffd5d8) at example.c:6
6       for (n=0; n<10; n++) {
(gdb) break printf
Breakpoint 2 at 0x7ffff7e32100: file printf.c, line 28.
(gdb) commands 2
Type commands for breakpoint(s) 2, one per line.
End with a line saying just "end".
>backtrace
>continue
>end
(gdb) continue
Continuing.

Breakpoint 2, __printf (format=0x402010 "Print Number: %d\n") at printf.c:28
28  {
#0  __printf (format=0x402010 "Print Number: %d\n") at printf.c:28
#1  0x0000000000401152 in main (argc=1, argv=0x7fffffffd5d8) at example.c:7
Print Number: 0

Breakpoint 2, __printf (format=0x402010 "Print Number: %d\n") at printf.c:28
28  {
#0  __printf (format=0x402010 "Print Number: %d\n") at printf.c:28
#1  0x0000000000401152 in main (argc=1, argv=0x7fffffffd5d8) at example.c:7
Print Number: 1

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .