gdbserverで共有ライブラリをデバッグ

Question

ターゲットとCodeSourcery IDEでgdbserverを使用しています。私のハードウェアはomap3530のgumstixです。

私は私のメインのアプリケーションにコードをステップ実行することができますが、私は、私はメモリアドレスを取得し、共有ライブラリ内の関数にステップインしようとしている場合、デバッガは終了します。

これは、ターゲットシステム上でコンパイルおよび/ libフォルダにコピーされ、私のライブラリです。（それはデバッグシンボルを持っている）私は

solib絶対プレフィックス/ libに設定し.gbdinitファイルを使用しようとしましたここ

は、GDBのトレースからの警告です：

903,056 13-gdb-set sysroot-on-target /lib 
903,065 13^done 
903,065 (gdb) 
903,065 14-target-select remote 192.168.1.101:2345 
903,114 =thread-group-started,id="i1",pid="42000" 
903,114 =thread-created,id="1",group-id="i1" 
903,115 15-list-thread-groups --available 
903,120 16-list-thread-groups 
903,128 &"warning: Unable to find dynamic linker breakpoint function.\nGDB will be unable to debug shared library initializers\nand track explicitly loaded dynamic code." 
903,128 &"\n" 

あなたはあなたのホストにインストールされているライブラリをデバッグすることができ

903,395 &"Error while mapping shared library sections:\n" 
903,397 &"/lib/libCoreLib.so: Invalid argument.\n" 
903,399 =library-loaded,id="/lib/libCoreLib.so",target-name="/lib/libCoreLib.so",hostname="/lib/libCoreLib.so",low-address="0x0",high-address="0x0",symbols-loaded="0",thread-group="i1" 

Answer 1

につながる、debuggを提供しました開発マシンでもあります。この場合、set sysroot-on-targetの代わりにset sysrootを使用します。たとえば：/home/username/.../rootfs/がターゲットファイルシステム

のコピーだと思うが含まれてい

set sysroot /home/username/.../rootfs/ 

は、あなたはまた、デバッグ中/代わりの/lib

Answer 2

同様の問題が発生しました指定してください。デバッグがハングアップしていました。 Ubuntuの12.04LTS

IDE：Eclipseのケプラー

ターゲット：Beagleboneブラック/ ARM A8

OS：オングストローム

ホストを次のように設定があります

ソリューション

更新ライブラリとEclipse

でのプロジェクトのための

プロパティを選択

• C/C++一般>パスと記号>（TABを含める）GNU C>追加>ファイル を含みシステム> /> usr/usr/lib/gcc/i686-linux-gnu/4/6 /からの変更/ usr/arm-linux-gnueabi/includeへの の変更

• C/C++一般>パスと記号>（TABを含める）GNU C++>>
  ファイルシステム> /> USR /usr/arm-linux-gnueabi/include/c++/4.6ます。3 /腕のlinux-gnueabi

• C/C++一般>パスと記号>（ライブラリパスTAB）>追加>ファイル システム> /> USR /は/ usr /腕-linuxの-gnueabi libの

Answer 3

良い一日、GDBの「デバッグ・ファイル・ディレクトリ」変数が正しく設定されていない場合

、 は、報告されたエラー・メッセージが含まれています 警告：ダイナミックリンカブレークポイント機能を見つけることができません。

ターゲットのルートファイルシステムは、次の2つのコマンドは、

は/ opt /腕のlinux-gnueabihf-rootfsので私のホストPC上に配置され、リモートデバッグがGDBを使用してgdbserverを経由して を作業得るために私を助けた（V7 .11.1）：

set debug-file-directory /opt/arm-linux-gnueabihf-rootfs/usr/lib/debug 
set sysroot /opt/arm-linux-gnueabihf-rootfs 

私は「SYSROOT」は、パスの末尾にスラッシュを持っている場合、 はその後、GDBがリモートターゲットに接続した後）it.Youこの（誤った出力が表示されます使用することができないことに気付きました：

代わりに、正しい出力の

Reading /lib/ld-linux-armhf.so.3 from remote target... 

又は

Reading symbols from /opt/arm-linux-gnueabihf-rootfs/lib/ld-linux- 
armhf.so.3...(no debugging symbols found)...done 

：

Reading symbols from /opt/arm-linux-gnueabihf-rootfs/lib/ld-linux- 
armhf.so.3... 
Reading symbols from /opt/arm-linux-gnueabihf-rootfs/usr/lib/debug/ 
lib/arm-linux-gnueabihf/ld-2.23.so...done. 

よろしく、 Frikkie Thirion

Answer 4

デバッグシンボルとターゲット

これは最もシンプルな方法で作業することができます。これは、特定の共有ライブラリを開発する場合に特に便利です。

まずコピーデバッグ情報付き対象にテスト実行可能ファイルと共有ライブラリ：readelf ----debug-dump=decodedline libmyib.soと

• チェック：How can I tell if a library was compiled with -g?
• コンパイル出力が取得するように、私は、ホスト上でNFSサーバーを使用することをお勧めします編集後に自動的にアップロードされます

次に対象：

gdbserver --multi :1234 ./executable_name 

ホスト：

arm-linux-gnueabihf-gdb -q -nh \ 
    -ex "target extended-remote target-hostname-or-ip:1234" \ 
    -ex "file ./executable_name" \ 
    -ex 'tb main' \ 
    -ex 'c' \ 
    -ex 'set solib-search-path .' 

sharedlibrary libmylib.soも動作します。

mainの前に、gdbserverがダイナミックローダーで停止し、その時点でダイナミックライブラリがまだロードされていないため、GDBはシンボルがまだメモリに格納されていないことを知りました。

GDBには共有ライブラリシンボルが自動的にロードされるようで、ホスト用にコンパイルしてgdbserverをローカルに実行すると、mainに実行する必要はありません。しかし、ARMターゲットでは、これが最も信頼できるものです。

ターゲットgdbserver 7.12-6、ホストarm-linux-gnueabihf-gdb 7.6.1 from Linaro。デバッグシンボル

なし

ターゲットライブラリのデバッグ情報が方法大きなそれらを作るので、組み込みターゲットに展開する前に、ターゲットライブラリを除去するのが一般的です。

たとえば、Buildrootはデフォルトでこれを行いますが、BR2_STRIP_none=yで無効にすることができます。

あなたは実行することによって、このシナリオを識別することができます

From    To     Syms Read Shared Object Library 
0x00007ffff7df7f90 0x00007ffff7dfcdd7 Yes (*)  target:/lib/ld64-uClibc.so.0 
0x00007ffff7b3a9b0 0x00007ffff7bbe05d Yes (*)  target:/lib/libc.so.0 
(*): Shared library is missing debugging information. 

はとてもデバッグ情報が欠落していることを述べているライブラリの両方のためのアスタリスク（*）があります。

info shared 

のようなものを示しています。

これが当てはまる場合は、の共有ライブラリを使用するようにGDBに指示してから、を削除してください。このオプションがある場合は

set sysroot buildroot/output/staging/ 

：それは彼らがターゲットと同じ相対パスを剥奪し、中にされる前に、共有ライブラリが含まれているstagingディレクトリを維持して例えば

Buildrootは、私たちのためにそれが容易になりますセット、gdbはすぐに代わり、ターゲットのホストでライブラリを検索し、パス+ /lib/libc.so.0buildroot/output/staging/で/lib/libc.so.0を見つける：

Reading symbols from buildroot/output/staging/lib/ld64-uClibc.so.0...done. 
Reading symbols from buildroot/output/staging/lib/libc.so.0...done. 

TODO：sysrootを複数設定することはできないと思うので、すべての共有ライブラリをターゲットイメージと同じ相対パスに配置する必要があります。

あなたが悪いデフォルトSYSROOTを確認した場合は、表示されます。

show sysroot 

ギブ：

target: 

デフォルトでは、ターゲットのルート/上の共有ライブラリのためにそのgdb検索を意味します。