Ctrl+C when a watchpoint is set gdb

["Siva Velusamy" <siva.velusamy@gmail.com>]

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