4
votes

Suppose I start a gdb session, and create a breakpoint and run.

After I break, I create a watchpoint based on the memory address of a symbol in the current execution, and delete the original breakpoint.

Some time later, I interrupt the program with Control-C, still inside gdb, I issue the run command to restart the program from the beginning.

However, I would like to preserve the hardware watchpoint across the restart of the debugged process.

Is there a gdb setting that allows me to preserve hardware watchpoints across reruns?


Update: Here is an example to reproduce the problem.

int main(){
    int NeverGoOutOfScope = 0;
    NeverGoOutOfScope = 7;
    while (1);
}

Here are the sequence of gdb commands.

break 3
run
watch NeverGoOutOfScope
info watch 
run 
# After this point, the breakpoint remains but the watchpoint is gone.
info watch

Is it possible to preserve the watchpoint without having to recreate it?

1
aren't they preserved by default?W.F.
Nope. The watchpoints disappear. The breakpoints may be preserved.merlin2011
I'm getting the warning Error in re-setting breakpoint NUMBER: No symbol "variable_name" in current context, but it leaves the watchpoint in the breakpoints list: NUMBER hw watchpoint keep y variable_name and its value is getting printed in the next run...W.F.
Is there any simple way to reproduce your issue?W.F.
I'll update when I get back on the computer.merlin2011

1 Answers

2
votes

It should work with two conditions: first, that you disable address space randomization; and second, that you use watch -location.

To disable randomization, use:

(gdb) set disable-randomization on

I think this is the default, so you might be able to skip this.

Next, use:

(gdb) watch -location NeverGoOutOfScope

This will record the address of the variable in the watchpoint. This is almost always what you actually want -- gdb has some fancy code to re-evaluate watchpoint expressions when a variable goes out of scope, but in practice I think this is more confusing than helpful.

This approach works for me on your test, though I have to ignore a few hits of the watchpoint during process initialization.