linux - 共有ライブラリをランタイムデバッグする方法は?

Question

共有ライブラリで実行時デバッグを行う方法を誰か教えてもらえますか?

共有ライブラリ内の関数をランタイム デバッグする必要がありますが、別のプログラムによって呼び出されます。共有ライブラリを使用して dbx のようなことを行うにはどうすればよいですか?

AIX で dbx を使用しています。私がやろうとしていることについて、gdbはdbxよりも優れていますか?.

Answer 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)

Answer 2

通常、共有ライブラリをデバッグする手順は、実行可能ファイルをデバッグする手順とほとんど同じです。主な違いは、共有ライブラリがメモリにロードされるまでブレークポイントを設定できない場合があることです。デバッガーをメインの実行可能ファイルに接続します。

自分が所有していないアプリケーションをデバッグしているが、プラグインアーキテクチャでモジュールを使用している場合でも、同じ方法を使用します。（いつものように）共有ライブラリで利用可能なデバッグ情報があることを確認してください。Windowsでは、.pdbファイルを生成します。gccでは、デバッグ情報が確実に提供されるように、特別なコンパイラフラグ（-g？）を指定すると思います。デバッガーをサードパーティアプリケーションに接続します。

Answer 3

lotharの答えにさらに別の例：

と呼ばれるPythonの単体テストライブラリを使用して、Linuxの動的ライブラリtest.so（からコンパイルされた）でテストを実行しています。（ネーミングスキームは少し単調です、今気づきました）test.cpythonunittesttests/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

Answer 4

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

Answer 5

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

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

Answer 6

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