Как отлаживать разделяемые библиотеки времени выполнения?

Ответ 1

Вам просто нужно вызвать gdb с исполняемым файлом (неважно, является ли он вашим или сторонним). Вот пример, когда я отлаживаю команду ls и устанавливаю точку останова в (общей) библиотеке c. В этом примере используется gdb 6.8, который поддерживает отложенные (ожидающие) точки останова, что делает это проще:

gdb /bin/ls
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
(no debugging symbols found)
(gdb) b write
Function "write" not defined.
Make breakpoint pending on future shared library load? (y or [n]) y
Breakpoint 1 (write) pending.
(gdb) r
Starting program: /bin/ls
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
(no debugging symbols found)
[Thread debugging using libthread_db enabled]
(no debugging symbols found)
(no debugging symbols found)
[New Thread 0x7f98d2d23780 (LWP 7029)]
[Switching to Thread 0x7f98d2d23780 (LWP 7029)]

Breakpoint 1, 0x00007f98d2264bb0 in write () from /lib/libc.so.6
(gdb)

Как вы можете видеть, gdb автоматически управляет всеми потоками, используемыми исполняемым файлом. Вам не нужно делать ничего особенного для потоков там. Точка останова будет работать в любом потоке.

Альтернативно, если вы хотите присоединить отладчик к уже запущенному приложению (здесь я использую tail -f/tmp/ttt):

ps ux | grep tail
lothar    8496  0.0  0.0   9352   804 pts/3    S+   12:38   0:00 tail -f /tmp/ttt
lothar    8510  0.0  0.0   5164   840 pts/4    S+   12:39   0:00 grep tail

gdb
GNU gdb 6.8-debian
Copyright (C) 2008 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu"...
(no debugging symbols found)
(gdb) attach 8496
Attaching to program: /usr/bin/tail, process 8496
Reading symbols from /lib/librt.so.1...(no debugging symbols found)...done.
Loaded symbols for /lib/librt.so.1
Reading symbols from /lib/libc.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.6
Reading symbols from /lib/libpthread.so.0...(no debugging symbols found)...done.
[Thread debugging using libthread_db enabled]
[New Thread 0x7f24853f56e0 (LWP 8496)]
Loaded symbols for /lib/libpthread.so.0
Reading symbols from /lib/ld-linux-x86-64.so.2...
(no debugging symbols found)...done.
Loaded symbols for /lib64/ld-linux-x86-64.so.2
(no debugging symbols found)
0x00007f2484d2bb50 in nanosleep () from /lib/libc.so.6
(gdb) b write
Breakpoint 1 at 0x7f2484d57bb0
(gdb) c
Continuing.
[Switching to Thread 0x7f24853f56e0 (LWP 8496)]

Breakpoint 1, 0x00007f2484d57bb0 in write () from /lib/libc.so.6
(gdb)

Ответ 2

Обычно процедура отладки разделяемой библиотеки такая же, как и для отладки исполняемого файла. Главное отличие заключается в том, что вы не можете установить точку останова до тех пор, пока общая библиотека не будет загружена в память. Вы присоединяете отладчик к основному исполняемому файлу.

Если вы отлаживаете приложение, которое не принадлежит вам, но использует ваш модуль в плагиновой архитектуре, вы все равно используете тот же метод. Убедитесь, что (как всегда) у вас есть отладочная информация, доступная для вашей общей библиотеки. В Windows вы создадите файл .pdb. С gcc, я думаю, вы указали специальный флаг компилятора (-g?), Чтобы обеспечить доставку информации отладки. Вы присоединяете отладчик к стороннему приложению.

Ответ 3

Еще один пример для ответа лота:

Я запускаю тесты в динамической библиотеке test.so (скомпилированные из test.c) в Linux с помощью python и библиотеки тестирования модулей python unittest, называемой tests/test_pwmbasic.py. (схема именования немного монотонна, я понимаю, что сейчас)

~/my/test/path/
    tests/
        __init__.py
        test_pwmbasic.py
    test.c
    test.so

Я хочу отладить, что в test.so от стимула в test_pwmbasic.py. Так вот как я заработал...

$ cd ~/my/test/path
$ gdb $(which python)
   ... gdb blah ...
(gdb) b test.c:179
(gdb) run
>>> from tests.test_pwmbasic import *
>>> import unittest
>>> unittest.main()
   ... unittest blah ...
Breakpoint 1, pwmTest_setDutyCycles (dutyCycles=0x7ffff7ece910) at ./test.c:179
(gdb) print pwm_errorCode
$1 = PWM_ERROR_NONE

и теперь я хочу жениться на gdb

Примечание: test.c также включает ../pwm.c, поэтому я также могу использовать точку останова в этой библиотеке с помощью

(gdb) b pwm.c:123

Ответ 4

Я помню, как тестировал разделяемые библиотеки, создав приманное приложение, которое его использовало. Если вы готовы много работать, вы можете создать вторую, разделяемую библиотеку, которая собирает информацию о том, как библиотека используется сторонним приложением, а затем воспроизводит эту информацию. >

Конечно, никогда не сомневайтесь в возможности хорошо отлаженных вызовов printf и fprintf.

Ответ 5

Прошло много времени с тех пор, как мне пришлось использовать dbx в AIX, и я тоже столкнулся с этой проблемой. Установка gdb не была для меня вариантом.

dbx  /path/to/your/program
(dbx) run [args to your program]
(dbx) set $ignoreonbptrap           # I kept hitting a trace/bpt trap
(dbx) set $deferevents              # allows setting bp in not loaded shared library
(dbx) set $repeat                   # useful, repeat commands with <enter> tjust like gdb
(dbx) stop in MySharedLibraryFunc   # defers breakpoint
(dbx) cont

Ответ 6

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