Ctrl+C when a watchpoint is set gdb

Ctrl+C when a watchpoint is set gdb

[Siva Velusamy]

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

Re: Ctrl+C when a watchpoint is set gdb

[Daniel Jacobowitz]

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

Re: Ctrl+C when a watchpoint is set gdb

[Siva Velusamy]

On Nov 6, 2007 6:41 PM, Daniel Jacobowitz <drow@false.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

Re: Ctrl+C when a watchpoint is set gdb

[Daniel Jacobowitz]

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