共有ライブラリを実行時にデバッグする方法は？

StackOverflow https://stackoverflow.com/questions/801423

  •  03-07-2019
  •  | 
  •  

質問

共有ライブラリでランタイムデバッグを行う方法を教えてもらえますか？

共有ライブラリ内の関数をランタイムデバッグする必要がありますが、別のプログラムによって呼び出されます。 共有ライブラリを使用して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の答えのさらに別の例：

python とpythonのユニットを使用して、Linuxで動的ライブラリ test.so （ test.c からコンパイル）でテストを実行しています- tests / test_pwmbasic.py というライブラリ unittest のテスト。 （命名スキームは少し単調ですが、今では気づいています）

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

test_pwmbasic.py のスティミュラスから test.so の内容をデバッグしたい。 だからこれは私がそれを機能させた方法です... 

$ 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

共有ライブラリを使用する模擬アプリを作成して、共有ライブラリをテストしたことを覚えています。多くの作業を行う場合は、サードパーティアプリでライブラリがどのように使用されているかについての情報を収集する2番目のモック共有ライブラリを作成し、モックアプリにその情報を再生させることができます。

もちろん、適切に配置されたprintfおよびfprintf呼び出しの威力を疑うことはありません。

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

ライブラリを静的にコンパイルおよびリンクして、デバッグすることができます。
共有としてコンパイルされたときにのみバグが表示される場合、いくつかの手がかりが得られる可能性があります。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top