2011-12-28 12 views
14

kvm vmでLinuxカーネルをデバッグしようとしています。エラーメッセージ "リモート 'g'パケットの応答が長すぎます。私のホストは64ビットで、私のVMもそうです。リモート 'g'パケット応答が長すぎます

マイ手順:

    は、カスタム-kernel、-initrdと-appendオプションを使用してVMを起動し
  1. スタートgdbの
  2. "i386アーキテクチャを設定:x86-64の:インテル" を実行
  3. "を追加し、シンボルファイルのlinux-3.0 /のvmlinux"
  4. 実行 "ショーのアーチを" そのまだ「i386のを確認するために実行:x86-64で:インテル」
  5. 実行 "をターゲットリモートlocalhostを:
  6. でCtrl + C "継続" を実行
  7. " 1234を、私は上記のメッセージが表示されます。

誰もがこの問題に直面しましたか?

+0

私のVMはubuntuを実行し、ホストはdebianを実行しています – contemplatingzombie

+0

gdbコードが表示された場合、remote.c/*リモートプロトコルの説明。 */long sizeof_g_packet;期待通りのものではありません。あなたのgdbserverが正しく設定されていないように見えます(私はそれほど確信していません)。 GDBサーバーを起動していますか?はいの場合、GDBとGDBSERVERのバージョンは一致しますか? – Kamath

+0

GDBのbugtrackerに似ています:https://sourceware.org/bugzilla/show_bug.cgi?id=13984 –

答えて

8

私も同じ問題に直面し、私はあなたがここにパッチを確認することができますset arch i386:x86-64

を渡すことによって、アーキテクチャが64ビットであることを常に64ビットのレジスタを送信する(QEMUソースで)gdbstub.cを変更し、GDBをヒンティングによって、それを修正: を訪問[URLはもはや利用できません]

+0

ありがとうございます。私はいつか試してみる。 – contemplatingzombie

+3

私はQEMUにパッチを当てる必要はありませんでした.GDB 'set arch i386:x86-64'だけで十分であると私には分かりました。 –

+0

...あなたのURLは現在廃止されています。 –

11

gdbは、実行時に命令セットを切り替えるCPUに対してうまく機能しません。接続する前にカーネルが早めに起動するのを待ち、qemuの-Sフラグを使用しないでください。

+0

-Sオプションを削除した後、私のために完全に働いた –

+0

それは私のために働いた! –

+4

はい、しかし* how *?私はクラッシュする前にカーネルを停止する必要があります。クラッシュする前に停止するには 'gdb'が必要です。私が "待機"すると、カーネルがクラッシュします。 :P – Thanatos

5

私は起動プロセスの初期段階でgdbに接続するのと同様の問題を発見しました。他の回答に記載されているように、gdbはその下のレジスタのサイズをあまり気にしません。この問題set debug remote 1を使用して見ることができます。

(gdb) set debug remote 1 
(gdb) target remote localhost:1234 
Remote debugging using localhost:1234 
... 
Sending packet: $g#67...Ack 
Packet received: 000000000000000... <~600 bytes> 
(gdb) until *0x1000 # at this address we'll be in a different cpu mode 
... 
Sending packet: $g#67...Ack 
Packet received: 10000080000000000000000000000000800000c... <~1000 bytes> 
... 
Remote 'g' packet reply is too long: 1000008000000000000000000... 
(gdb) 

Patching gdb to resize its internal buffer when it sees a too-large packet (他の場所と)GDBのバグトラッカーでこの問題に見られるように、実際にのみ64ビットを送信するためにQEMUをパッチんので、問題を回避んサイズのパケット。しかし、the latter solution breaks debugging in non-64-bit-modesは、かつての修正が不完全になることができると思わ:それはかなり間違って聞こえる

GDBがそれをデバッグすでにのとき GDBの背中の後ろにターゲットを変更すること。 g/Gパケットのサイズ だけでなく、誤ってレイアウトが変更されることもあります。 ターゲット設定があなたの再設定で変更された場合は、 の説明が表示されます.GDBはターゲット全体をフェッチ/再計算する必要があります。 今日は、 の切断/再接続でのみ行うことができると思います。

からhttps://sourceware.org/ml/gdb/2014-02/msg00005.html

切断/動作しているように見えない記事の最後に言及した回避策を再接続:

(gdb) disconnect 
Ending remote debugging. 
(gdb) set architecture i386:x86-64 
The target architecture is assumed to be i386:x86-64 
(gdb) target remote localhost:1234 
Remote debugging using localhost:1234 
(gdb) info registers 
rax   0x80000010 2147483664 
rbx   0x0 0 
... 
+2

もう一度 '' target remote localhost:1234'を実行した直後に ''リモート 'g'パケットが長すぎます。 – Thanatos

+0

@Thanatosそれは私のために働いた。ここに私の詳細なセットアップがあります:http://stackoverflow.com/questions/4943857/linux-kernel-live-debugging-how-its-done-and-what-tools-are-used/42316607#42316607 –

0

は、私が誤ってGDBへの引数としてバイナリ名を省略していました。これは私のために働いた。

Remote debugging using localhost:1234 
0xffffffff81025f96 in default_idle() 

デバッガはそうあなたがそれを提供してくださいのvmlinux必要があります。その後、

$ gdb ./vmlinux 
(gdb) target remote localhost:1234 

し、出力を得ました。 OPには別の問題がありますが、私の答えはgdbに引数を提供することを忘れてOPと同じエラーメッセージで終わった人に役立つかもしれません。

関連する問題