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

On Tue, Nov 06, 2007 at 06:32:04PM -0800, Siva Velusamy
wrote:
> 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.

You shouldn't be getting to the call to
bpstat_explains_signal at all.
Is your remote stub returning the wrong signal for C-c?  It
should be
TARGET_SIGNAL_INT, not TARGET_SIGNAL_TRAP.

-- 
Daniel Jacobowitz
CodeSourcery

On Nov 6, 2007 6:41 PM, Daniel Jacobowitz <drowfalse.org> wrote:
> On Tue, Nov 06, 2007 at 06:32:04PM -0800, Siva Velusamy
wrote:
> > 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.
>
> You shouldn't be getting to the call to
bpstat_explains_signal at all.
> Is your remote stub returning the wrong signal for C-c?
 It should be
> TARGET_SIGNAL_INT, not TARGET_SIGNAL_TRAP.
>

Yes, it is returning TARGET_SIGNAL_TRAP. I will see if
making it
TARGET_SIGNAL_INT fixes the issue. Following up on your
comment, I
looked through the definitions of all the signals in
signals.c, and I
don't think the remote server followed many of the
conventions. Thanks
for the pointer!

-Siva

On Tue, Nov 06, 2007 at 06:48:25PM -0800, Siva Velusamy
wrote:
> Yes, it is returning TARGET_SIGNAL_TRAP. I will see if
making it
> TARGET_SIGNAL_INT fixes the issue. Following up on your
comment, I
> looked through the definitions of all the signals in
signals.c, and I
> don't think the remote server followed many of the
conventions. Thanks
> for the pointer!

No problem.  The documentation is not very clear about the
need to
do this; improving that is on my list.

-- 
Daniel Jacobowitz
CodeSourcery