This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Ctrl+C when a watchpoint is set gdb
- From: "Siva Velusamy" <siva dot velusamy at gmail dot com>
- To: gdb at sourceware dot org
- Date: Tue, 6 Nov 2007 18:32:04 -0800
- Subject: Ctrl+C when a watchpoint is set gdb
Hello,
I'm trying to debug the following strange gdb behavior on an embedded target:
(gdb) watch foo
(gdb) c
(gdb)
Hardware watchpoint 2: foo
Old value = 0
New value = 10
call_func (a=<value optimized out>) at bar.c:4
4 }
(gdb) c
Continuing.
<--------------------- At this point Ctrl+C does not stop gdb.
What happens is that when a Ctrl+C is pressed, gdb receives control,
goes into infrun.c and checks if the processor has stopped due to an
existing breakpoint. (The only existing breakpoint is a watchpoint on
foo.)
However, the function bpstat_explains_signal is defined as follows:
breakpoint.h:547
/* Nonzero if a signal that we got in wait() was due to circumstances
explained by the BS. */
/* Currently that is true if we have hit a breakpoint, or if there is
a watchpoint enabled. */
#define bpstat_explains_signal(bs) ((bs) != NULL)
Since there is a watchpoint defined, this ends up evaluating to true,
even though this is a trap signal caused by Ctrl+C. Eventually, this
leads to keep_going(ecs) being called.
In cases where a watchpoint is not defined, then ecs->random_signal
ends up being 1, and gdb gives control back to the user.
This happens for two cpu targets: powerpc 405 and MicroBlaze.
Could someone point me in the right direction as to what exactly to
look for? The PowerPC target is pretty much unmodified gdb-6.5, so I'm
surprised that doesn't work.
Thanks!
--
In the end, everything is a gag.
Charlie Chaplin