誰でも共有ライブラリでランタイムデバッグを行う方法を教えてもらえますか?
共有ライブラリの関数をランタイムデバッグする必要がありますが、別のプログラムによって呼び出されます。共有ライブラリを使用してdbxなどを実行するにはどうすればよいですか?
AIXでdbxを使用しています。私がやろうとしていることについて、gdbはdbxよりも優れていますか?.
実行可能ファイルを使用して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)
通常、共有ライブラリのデバッグ手順は実行可能ファイルのデバッグの手順とほとんど同じです。主な違いは、共有ライブラリがメモリにロードされるまでブレークポイントを設定できない場合があることです。デバッガをメインの実行可能ファイルに添付します。
自分が所有していないが、プラグインアーキテクチャでモジュールを使用しているアプリケーションをデバッグしている場合でも、同じ方法を使用します。 (いつものように)共有ライブラリで利用可能なデバッグ情報があることを確認してください。 Windowsでは、.pdbファイルを生成します。 gccでは、特別なコンパイラフラグ(-g?)を指定して、デバッグ情報が提供されるようにします。デバッガーをサードパーティのアプリケーションにアタッチします。
Lotharの答えのさらに別の例:
Linuxでpython
とpythonの単体テストライブラリunittest
と呼ばれるtest.so
を使用して、動的ライブラリtest.c
(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
AIXでdbxを使用する必要があったのは久しぶりで、この問題にも直面しました。私にとって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
共有ライブラリを使用する模擬アプリを作成して、共有ライブラリをテストしたことを覚えています。多くの作業を実行する場合は、サードパーティのアプリでライブラリがどのように使用されているかに関する情報を収集する2つ目のモック共有ライブラリを作成し、モックアプリにその情報を再生させることができます。
もちろん、適切に配置されたprintfおよびfprintf呼び出しの力を疑うことはありません。
ライブラリを静的にコンパイルおよびリンクして、デバッグすることができます。
共有としてコンパイルされたときにのみバグが表示される場合、それはいくつかの手がかりを与える可能性があります。