問題タブ [gdbserver]

アプリが JNI を介して使用するネイティブ共有ライブラリをデバッグしようとしています。「gdbserver --attach pid」を使用して実行中のアプリに問題なくアタッチできますが、gdbserver コマンドを起動するときに実際にアプリを起動する必要があります。

このトピックには 100 万件のブログ ヒットがありますが、どのようにアプリを起動するかについて明確にしているようには見えません。彼らはすべて「gdbserver 10.0.2.2:1234 ./MyProgram」と入力するように言っていますが、正確には「MyProgram」とは何ですか。それは MyProgram.apk ですか？MyProgram.soですか？アプリのインストール時に作成される他のファイルですか？もしそうなら、その経路は何ですか？

gdbのサーバーモードを使用してコードをリモートデバッグすることが可能であり、別のアーキテクチャ用にクロスコンパイルされたコードをデバッグすることも可能ですが、さらに一歩進んで、OSXからLinuxアプリケーションをリモートでデバッグすることは可能です。 gdbserver？

JNI を使用するコードがいくつかあります。Java で記述されたコードを Eclipse で (ADT を使用して) 直接デバッグできます。gdb でネイティブ コードをデバッグするのに役立つスクリプトもあります。ただし、これはあまり快適な方法ではありません。

Androidネイティブアプリケーションのデバッグにgdb(gdbserverだと思います)を使用するようにEclipseを構成することは可能ですか? これについての説明がどこにあるかわかりますか？

ネットワークに接続され、/homeマウントを共有する2台の同一の64ビットCentos5マシンがあります。単純なHelloWorldプログラムを一方にコンパイルしてから、一方のマシンでgdbを使用して、もう一方のマシンで実行されているプログラムをリモートでデバッグする方法を理解しました。全員がデフォルトで64ビットネスに設定されている場合、これは正常に機能するようです。

ただし、Hello Worldを-m32でコンパイルして32ビットのバイナリを生成すると、システム全体がコンパイルされる方法で、gdbとgdbserverを正しく接続する方法がわかりません。フルアップシステムで試す前に、helloで動作させる必要があると思います。gdbとgdbserverを接続しようとする方法に応じて、不適切な形式のレジスタに関するメッセージ、アーキテクチャの不一致に関する警告、または不正なメモリ参照のいずれかが表示されます。

-m32がコンパイルにどのような影響を与えるかについてはほとんど理解しておらず、gdbとgdbserverを起動する方法や、アーキテクチャやファイルなどを指定する正しい順序についても理解していないようです。:(

64ビットLinuxボックスの32ビット（-m32）実行可能ファイルでgdbとgdbserverを使用するには何が必要ですか？

以下の例、そしてありがとう、

ジェリー

hello.cpp：

これが3つの実行です：

1. gdbで、アーキテクチャi386を設定し、gdbserverに接続します=>不正なアーキテクチャ
2. gdbで、アーキテクチャi386 / file hello /を設定し、gdbserverに接続します=>不正なアーキテクチャ
3. gdbで、アーキテクチャを（誤って）設定しますi386：x86-64 / filehello/次にgdbserverに接続します=>メモリにアクセスできません

またはもう少し詳しく：

==============================

実行ごとに、リモートgdbserverは次のように述べています。

そして私たちの地元で：

==============================

• i386 32ビットであると仮定し、archiをi386に設定してから、接続します。注：gdb側では、実行可能ファイルが指定またはロードされていません。

==============================

• i386 32ビットであると仮定し、archiをi386に設定してから、接続します。注：gdb側では、実行可能ファイルにファイルがロードされています。

==============================

• それがi386：x86-64であると仮定し、archiをi386：x86-64に設定してから、接続します。注：gdb側では、実行可能ファイルにファイルがロードされています。

target remote コマンドを使用して gdb を使用してコマンドラインでデバイスを管理するときに、Eclipse CDT を使用してデバイスをリモートでデバッグできない理由を知っている人はいますか? 接続時に警告が表示されますが、それ以外は問題なく動作しているようです。

Eclipse では正しい設定が必要であり、gdbserver は接続が確立されたことをリモート マシンに通知しますが、その後 Eclipse はエラーを出します:「デバッグの起動」で問題が発生しました。リクエストが失敗しました: ターゲットが応答していません (タイムアウト)。リモートデバイスにも「Kill​​ing Inferior」と表示されます (これは gdb ではわかりません)。エラーログには他に何も表示されません。

どちらの場合も同じプロセス、バイナリおよび gdb 実行可能ファイルを使用し、同じデバイスとポートに接続しています。gdb 7.1 を使用しており、ホストは 64 ビットの Ubuntu Lucid です。

リモート Linux システムでビルドおよびテストされる C コードを開発するために、Windows で Eclipse CDT を実行しています。現在、コードが Windows でコンパイルされることはありません。

CDT を使用して、gdbserver の下の Linux ターゲットでリモート プロセスを開始し、Windows ホストから gdb を接続できます。ただし、gdb は次のようなエラーですぐに失敗します。

2 つの Linux システム間でのデバッグは問題なく機能するため、Windows ホスト側で何か間違ったことをしていることは明らかです。私の具体的な質問は次のとおりです。

• gdb の Cygwin バージョンは、リモートの Linux プロセスをデバッグするのに十分ですか?それとも、Windowsで実行して Linux プロセスを操作するには、特別な cross-gdb が必要ですか? もしそうなら、そのようなgdbを手に入れることができる場所はありますか?

• gdb を使用したリモート デバッグでは、ホスト システムでシンボルを使用できる必要があります。これを達成する最も簡単な方法は何ですか？Linux ターゲットでのビルドによって生成されたシンボルを Windows ホストにコピーすることはできますか? それとも、Windows で完全なビルドを実行する必要がありますか? ターゲットにのみシンボルを提供できるように、この要件を回避する方法はありますか?

ありがとう、

-R

詳細: RSE FAQにいくつかのヒントがありますが、残念ながらまだブロックされています。FAQ では、次の 2 つのアプローチについて説明しています。

• ssh を介してリモート システムで gdb クライアントを起動します。ここでの問題は、CDT デバッグ ランチャーの特定のフィールドがローカル システム (プロジェクト パス、実行可能パスなど) に関連付けられていることです。
• Windows からの Linux プロセスのデバッグをサポートする gdb のクロスデバッグ バージョンをビルド/取得します。ここでの問題は、これを達成する方法に関する情報がほとんどないことです。

CDT フォーラムでもこの問題を提起しました。

誰かがエラーメッセージを知っていますか？gdbserver [949] segfault at 81c ip 0000081c sp bfeef918 error 4 in gdbserver [8048000+1c0000]セグメンテーションフォールト

ありがとう、

リモートホストで fork プロセスをデバッグしようとしていますが、gdbserver プロセスが毎回子終了で終了します。

.gdbinit で「set follow-fork-mode child」を設定しようとしましたが、役に立ちませんでした。

これに対する良い解決策はありますか？

ありがとう。

リモート デバッグに問題があります。

ホスト: ubuntu 10.10 x86 を搭載したラップトップ Intel i5 ターゲット: Freescale iMX35 (iMX35 PDK) arm 11 開発環境: Qt Creator 2.1RC および Qt4.7.1 ライブラリ。パスの Arm コンパイラ: /opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin

arm-none-linux-gnueabi-gcc-4.1.2 arm-none-linux-gnueabi-objdump arm-none-linux-gnueabi-addr2line arm-none-linux-gnueabi-gccbug
arm-none-linux-gnueabi-ranlib arm -none-linux-gnueabi-ar
arm-none-linux-gnueabi-gcov arm-none-linux-gnueabi-readelf arm-none-linux-gnueabi-as
arm-none-linux-gnueabi-run arm-none-linux- gnueabi-c++
arm-none-linux-gnueabi-size arm-none-linux-gnueabi-c++filt
arm-none-linux-gnueabi-gprof arm-none-linux-gnueabi-strings arm-none-linux-gnueabi- cpp arm-none-linux-gnueabi-ld
arm-none-linux-gnueabi-strip arm-none-linux-gnueabi-g++
arm-none-linux-gnueabi-nm arm-none-linux-gnueabi-gcc
arm-none- linux-gnueabi-objcopy

目標は、Qt で作成されたプロジェクトをデバッグすることです。だから私は単にQtクイックプロジェクトを作成しました->単純なHello Worldアプリケーション（C ++ / Qml）を作成するQtクイックアプリケーションを作成しました（デバッグまたはリリースで）クロスコンパイルし、ターゲットで正常に動作します。したがって、クロス コンパイルはこれから紹介する問題とは無関係であると確信しています。

gdb 7.2 をダウンロードし、次の操作を実行しました。

$ export PATH=/opt/freescale/usr/local/gcc-4.1.2-glibc-2.5-nptl-3/arm-none-linux-gnueabi/bin:$PATH
$ cd /home/elux/iMX35/gdb- 7.2/
$ ./configure --target=arm-none-linux-gnueabi --build=i686
$ make
$ sudo make install

$ export CC=arm-none-linux-gnueabi-gcc
$ export LD=arm-none-linux-gnueabi-ld
$ cd gdb/gdbserver/
$ ./configure --build=i386 --host=arm-none-linux -gnueabi --target=arm-none-linux-gnueabi
$ make

$ sudo cp gdbserver /home/elux/MX35/ltib/rootfs/usr/bin/ (gdbserver をターゲットにコピーするため)

次に、ターゲットで：

$ gdbserver 10.10.10.1:4000 テスト
プロセス テストが作成されました。pid = 2194
ポート 4000 でリッスン

ターゲット上:

$ arm-none-linux-gnueabi-gdb Test (テストは、Qt Creator をデバッグ モードでクロスコンパイルしたものです) GNU gdb (GDB) 7.2
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL バージョン 3 以降http://gnu.org/licenses/gpl.html
これはフリー ソフトウェアです。変更や再配布は自由です。
法律で許可されている範囲で、保証はありません。詳細については、「コピーを表示」
および「保証を表示」と入力してください。
この GDB は、「--host=i686 --target=arm-none-linux-gnueabi」として構成されました。
バグ報告の手順については、http:
//www.gnu.org/software/gdb/bugs/ ...を参照してください。
/home/elux/iMX35/ltib/rpm/BUILD/qt-everywhere-opensource-src-4.7.1 /platform/Test-build-arm/Test...done からシンボルを読み取ります。
(gdb) target remote 10.10.10.2:4000
10.10.10.2:4000 警告を使用したリモート デバッグ
: XML ターゲットの説明を解析できません。コンパイル時の
警告で XML サポートが無効になりました: 動的リンカー ブレークポイント関数が見つかりません。GDB は、共有ライブラリの初期化子をデバッグしたり、明示的にロードされた動的コードを追跡したり
できなくなります。 0x400007e0 in ?? () (gdb)

と

(gdb) set solib-absolute-prefix /home/elux/iMX35/ltib/rootfs/ /home/elux/iMX35/ltib/rootfs/lib/ld-linux.so.3
からシンボルを読み取る...完了。
/home/elux/iMX35/ltib/rootfs/lib/ld-linux.so.3 のロードされたシンボル

しかし

(gdb) set architecture armv5te
The target architecture is assumed to be armv5te
Remote 'g' packet reply is too long: 00000000a7ee8ebe0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b0ed8ebe00000000e007004010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

(gdb) b main
Remote 'g' packet reply is too long: 00000000a7ee8ebe0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000b0ed8ebe00000000e007004010000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

この問題が何に関係しているのか分かりますか? どうすれば解決できますか？

cygwin ホストで Linux を対象としたアプリをクロスコンパイルしました。プログラムは、ターゲット上でも gdbserver でも正常に実行されます。ただし、プログラムをステップ実行しようとすると、共有ライブラリ関数にステップインするたびにクラッシュします。バックトレース gdb 出力は次のとおりです。

(gdb) bt
#0 0x00000000004008f4 in ?? ()
#1 0x0000003f0380d7e4 in ?? ()
#2 0x00002b1373630000 in ?? ()
#3 0x00002b1373630590 in ?? ()
#4 0x00002b1373631348 in ?? ()
#5 0x00002b1373631888 in ?? ()
#6 0x0000003f03a1c510 in ?? ()
#7 0x0000000000000000 in ?? ()

関数にブレークポイントを設定して続行すると、クラッシュしません。

これは hello.c です。

x86_64-unknown-linux-gnu-gcc -g -c hello.c でコンパイル。

および foo.c:

x86_64-unknown-linux-gnu-gcc -g -shared -Wl,-soname,libfoo.so -o libfoo.so foo.c でコンパイル。

リンクはx86_64-unknown-linux-gnu-gcc -Wl,-rpath, で行われます。libfoo.so hello.o -o こんにちは。