13

大規模な C アプリケーションで、次のようにメモリ アドレスにハードウェア ウォッチポイントを設定しました。

(gdb) watch *0x12F5D58
Hardware watchpoint 3: *0x12F5D58

ご覧のとおり、これはソフトウェアではなくハードウェアのウォッチポイントであり、速度の遅さを説明しています。

現在、デバッガーでのアプリケーションの実行時間は、10 秒未満から 1 時間に変わりました。ウォッチポイントはこれまでに 3 回トリガーされました。1 回目は、アドレスを含むメモリ ページが によって読み取り可能になった 15 分後sbrkです。この 15 分間はメモリ ページにアクセスできなかったので、ウォッチポイントは効率的だったはずです。そして、それはまだ説明していません。なぜ後で遅いのですか。

プラットフォームは x86_64 で、GDB のバージョンは Ubuntu 9.10 パッケージです。

$ gdb --version
GNU gdb (GDB) 7.0-ubuntu
[...]

ソースからビルドされたストック GDB 7.1:

$ gdb-7.1 --version
GNU gdb (GDB) 7.1

何が原因であるか、またはそれを修正/回避する方法についてのアイデアを事前に感謝します.

編集：キャストを削除

編集：gdb 7.1

4

4 に答える 4

9

大きな文字バッファーを監視するのは非常に遅いのに対し、そのバッファー内の文字を監視するのは非常に高速であることを発見しました。

例えば

static char buf[1024];
static char* buf_address = &buf;

watch buf_address- ひどく遅い。

watch *buf_address- とても早い。

于 2012-09-11T17:32:35.470 に答える
5

毎回キャストしている可能性が最も高いです。これを試して：

(gdb) watch *0x12F5D58

もう 1 つのオプションは、設定されているハードウェア ウォッチポイントが多すぎるため、gdb がソフトウェア ウォッチポイントを使用することを余儀なくされることです。使用しているウォッチポイントの数を確認してみてください。

(gdb) info break

いくつかのウォッチポイントを無効にできるかどうかを確認してください。

于 2010-03-15T09:51:21.353 に答える
5

実際、GDB 7.xx のハードウェア ウォッチポイントで問題が発生しましたが、私の仕事ではウォッチポイントが必要なので、これは受け入れられません。

同僚からのアドバイスで、6.7.1 のソースをダウンロードし、ローカルでビルドしました。ウォッチポイントの機能が大幅に改善されました。

試してみる価値があるかもしれません。

于 2010-03-19T20:04:30.040 に答える
1

x86では、次の制限があります。すべてのウォッチポイントがカバーできるメモリアドレスは4つまでで、メモリの各アドレスは1つのメモリワードを監視できます。これは、ハードウェアウォッチポイント（高速のもの）がプロセッサのデバッグレジスタを使用するためです。それらのうちの4つ、したがって4つの場所を監視する必要があります。

于 2012-08-14T23:54:16.297 に答える