2

プロジェクト全体のさまざまな関数やファイルで使用されるオブジェクトへのポインターを使用して、C++で定義されたオブジェクトがあります。更新中のデータに問題があるので、デバッグして何が起こっているかを確認したいと思います。理想的には、オブジェクトにアクセスするたびに中断したいと思います。ただし、watch特定のメモリアドレスが必要です。したがって、たとえば、私が持っている場合：

class data{
public:
    int a;
    int b;
};

aデータへのポインタがに向けられているため、gdbは変更された場合にのみ機能しますが、変更されaた場合は機能しませんb。

dataクラスがカバーするメモリの全範囲が変更されるたびに中断する方法はありますか？

4

1 に答える 1

4

データクラスがカバーするメモリの全範囲が変更されるたびに中断する方法はありますか？

多分。

GDBハードウェアウォッチポイントはハードウェアで特別なデバッグレジスタを使用し、通常、そのようなレジスタの動作には制限があります。で、最大4x86ワードサイズのハードウェアウォッチポイントを設定できます。たとえば、ウォッチポイントをとに設定できます。これにより、のメモリ全体が「カバー」されます。&data->a&data->bdata

でも、実際dataにはもっとたくさんのメンバーがいると思いますので、4ワードサイズのウォッチポイントでは不十分です。

Valgrindをサポートするプラットフォームを使用していて、プログラムがValgrindで実行できる場合は、Valgrindの組み込みgdbserverを使用して、メモリの任意の領域にウォッチポイントを設定できます。

アップデート：

リンク先のページを調べましたが、探していたものが見つかりませんでした

何を探していたのかわかりません。これがどのように機能するかを示すサンプルセッションです：

#include <stdlib.h>

void foo(char *p)
{
  *p = 'a';
}

typedef struct {
  char buf[1024];
} data;

int main()
{
  data *d = calloc(1, sizeof(data));
  foo(d->buf + 999);
}

gcc -g main.c

valgrind --vgdb-error=0 ./a.out
...
==10345== TO DEBUG THIS PROCESS USING GDB: start GDB like this
==10345==   /path/to/gdb ./a.out
==10345== and then give GDB the following command
==10345==   target remote | vgdb --pid=10345

... Valgrindは、デバッガーが接続するのを待機します。

別のウィンドウで：

gdb ./a.out
GNU gdb (GDB) 7.4
...
(gdb) target remote | vgdb --pid=10345
relaying data between gdb and process 10345
[Switching to Thread 10345]
0x0000000004000af0 in _start () from /lib64/ld-linux-x86-64.so.2
(gdb) b main
Breakpoint 1 at 0x40053d: file main.c, line 14.
(gdb) c

Breakpoint 1, main () at main.c:14
14        data *d = calloc(1, sizeof(data));
(gdb) n
15        foo(d->buf + 999);
(gdb) watch *d
Hardware watchpoint 2: *d

「ハードウェア」ウォッチポイントが全体 *dに設定されていることに注意してください。Valgrindがハードウェアであるという意味でのみ、ハードウェアの監視ポイントです。

(gdb) p d.buf[999]
$1 = 0 '\000'
(gdb) c
Hardware watchpoint 2: *d

Old value = {buf = '\000' <repeats 1023 times>}
New value = {buf = '\000' <repeats 999 times>, "a", '\000' <repeats 23 times>}
foo (p=0x51b6457 "a") at main.c:6
6       }
(gdb) q

出来上がり：999番目の要素が変更されたときにデバッガーが停止し、ウォッチポイントが構造全体を「カバー」したことを証明しました。

于 2012-09-07T15:28:24.973 に答える