GDB, входящий в общую библиотеку, показывает «нет такого файла», даже если загружены символы отладки - PullRequest
Новая
       12

GDB, входящий в общую библиотеку, показывает «нет такого файла», даже если загружены символы отладки

2 голосов
/ 25 марта 2020

У меня есть библиотека C, созданная с помощью 

cc -fPIC -g -O3   -c -o obj/my_lib.o my_lib.c
g++ -shared -Wl,-soname,libmy_lib.so.1  obj/my_lib.o -o libmy_lib.so.1.8.0

Эта библиотека упакована в пакеты debian с dpkg-buildpackage, создающими libmy_lib1-1.deb, libmy_lib1-dev-1.deb и libmy_lib1-dbgsym-1.ddeb. Установив все эти пакеты, я могу затем скомпилировать / связать простую тестовую программу, которая вызывает библиотеку. Это работает. Запуск тестовой программы работает.

Однако, когда я запускаю GDB в тестовой программе (на том же компьютере), я вижу 

gdb$ break main
Breakpoint 1 at 0x87e: file test.c, line 10.
gdb$ info sharedlibrary
No shared libraries loaded at this time.
gdb$ r
Starting program: /tmp/a.out

Breakpoint 1, main () at test.c:10
10        my_library_func();
gdb$ info sharedlibrary
From                To                  Syms Read   Shared Object Library
0x00007ffff7dd5f10  0x00007ffff7df4b20  Yes         /lib64/ld-linux-x86-64.so.2
0x00007ffff7bac9a0  0x00007ffff7bad438  Yes         /usr/lib/x86_64-linux-gnu/libmy_lib.so.1
0x00007ffff74532d0  0x00007ffff75cbc3c  Yes         /lib/x86_64-linux-gnu/libc.so.6
0x00007ffff709fa80  0x00007ffff715e2f5  Yes         /lib/x86_64-linux-gnu/libm.so.6
0x00007ffff6e7eac0  0x00007ffff6e8f36d  Yes         /lib/x86_64-linux-gnu/libgcc_s.so.1
(*): Shared library is missing debugging information.
gdb$ s
my_library_func () at my_lib.c:299
299     my_lib.c: No such file or directory.

Как вы можете видеть, GDB знает о символах отладки для библиотеки. Тем не менее, он не знает об исходном файле для библиотеки. Как мне запустить GDB, чтобы он мог разрешить исходный код C?

Ответы [ 2 ]

2 голосов
/ 25 марта 2020

Вы также должны указать GDB, где находятся исходные файлы. Это означает, что вам также нужны исходные файлы, а не только символы отладки.

Важно, чтобы загружаемые вами источники были именно теми, которые использовались для компиляции библиотеки, потому что информация об отладке содержит только имя файла и номер строки. Если вы дадите gdb файл, в котором номера строк не соответствуют (например, другой версии), исходные строки, напечатанные gdb, будут очень запутанными. Нет никакого способа узнать, что они не правы. Вы должны иметь возможность использовать deb sr c с тем же номером версии, что и библиотеки debs.

Получив исходные файлы, скажите gdb, где их искать с помощью 

directory /path/to/source/files

Вы можете указать несколько путей. Прочитайте help directory внутри gdb.

Поскольку вам придется делать это часто, поместите эту строку в файл gdbinit . Возможно, вы захотите использовать .gdbinit в вашем текущем каталоге, но .gdbinit в вашем домашнем каталоге также может быть возможным. Gdb использует оба.

Если вы работаете с библиотекой, чей источник распространяется по дереву подкаталогов, вам может быть полезно установить путь замены: 

set substitute-path /your/file/path /original/file/path

Опять же, больше Помощь доступна с help set substitute-path.

1 голос
/ 25 марта 2020

GDB ищет несколько путей к каталогам по умолчанию, чтобы найти указанный исходный файл. Вы можете добавить пути, используя команду directory: https://sourceware.org/gdb/current/onlinedocs/gdb/Source-Path.html

...