rwatchpoint configuration

rwatchpoint configuration

[Siva Velusamy]

Hello,

I am debugging a read watchpoint issue on an embedded target (Xilinx
MicroBlaze processor).

The issue I'm trying to resolve is that gdb breaks on a read
watchpoint _only_ if the value of the variable being watched has not
changed since the watchpoint was set. This comes from the following
condition in gdb:

gdb/breakpoint.c:2792

case WP_VALUE_CHANGED:
        if (b->type == bp_read_watchpoint)
              {
                  /* Don't stop: read watchpoints shouldn't fire if
                     the value has changed. This is for targets
                     which cannot set read-only watchpoints. */
                  bs->print_it = print_it_noop;
                  bs->stop = 0;
                  continue;
              }

Since the MicroBlaze target can indeed set read-only watchpoints, this
should not happen. It looks as if the target has not been properly
configured. Could someone point me to the appropriate configuration
settings and what the correct values should be for a processor that
natively supports read watchpoints?

Note that read watchpoints do work fine if the value has not changed
since the breakpoint was set. Also, the serial protocol packet
received looks like "T05watch:000014ec;" in one specific test when the
read watchpoint is hit.

Thanks,
Siva
-- 
In the end, everything is a gag.
           Charlie Chaplin

Re: rwatchpoint configuration

[Daniel Jacobowitz]

On Mon, Dec 17, 2007 at 04:42:51PM -0800, Siva Velusamy wrote:
> gdb/breakpoint.c:2792
> 
> case WP_VALUE_CHANGED:
>         if (b->type == bp_read_watchpoint)
>               {
>                   /* Don't stop: read watchpoints shouldn't fire if
>                      the value has changed. This is for targets
>                      which cannot set read-only watchpoints. */
>                   bs->print_it = print_it_noop;
>                   bs->stop = 0;
>                   continue;
>               }
> 
> Since the MicroBlaze target can indeed set read-only watchpoints, this
> should not happen. It looks as if the target has not been properly
> configured. Could someone point me to the appropriate configuration
> settings and what the correct values should be for a processor that
> natively supports read watchpoints?

I don't think there is an appropriate configuration knob at present.

Eli, I think I remember you discussing this with someone else, a year
or two ago; do you remember the reasoning?  If the watchpoint's type
is "only trigger on reads", then core GDB assuming it triggers on all
accesses seems problematic to me.

-- 
Daniel Jacobowitz
CodeSourcery

Re: rwatchpoint configuration

[Siva Velusamy]

> > Since the MicroBlaze target can indeed set read-only watchpoints, this
> > should not happen. It looks as if the target has not been properly
> > configured. Could someone point me to the appropriate configuration
> > settings and what the correct values should be for a processor that
> > natively supports read watchpoints?
>
> I don't think there is an appropriate configuration knob at present.
>
> Eli, I think I remember you discussing this with someone else, a year
> or two ago; do you remember the reasoning?  If the watchpoint's type
> is "only trigger on reads", then core GDB assuming it triggers on all
> accesses seems problematic to me.
>

I did see some references to such behavior. e.g:

http://sources.redhat.com/ml/gdb/2005-11/msg00242.html

However since it was ~ 2005, I assumed that was old.

-Siva

Re: rwatchpoint configuration

[Siva Velusamy]

>
> I don't think there is an appropriate configuration knob at present.
>
> Eli, I think I remember you discussing this with someone else, a year
> or two ago; do you remember the reasoning?  If the watchpoint's type
> is "only trigger on reads", then core GDB assuming it triggers on all
> accesses seems problematic to me.
>

In this thread:

http://sources.redhat.com/ml/gdb/2005-11/msg00251.html

Eli mentions that "If someone finds a way to announce a read
watchpoint when the value changed on a target that supports that,
without losing support for read watchpoints on x86 (which is by far
the most popular platform these days), I'll gladly agree to such a
change"

So I guess the question really is if there has been an update to this.

-Siva

Re: rwatchpoint configuration

[Daniel Jacobowitz]

On Mon, Dec 17, 2007 at 04:59:39PM -0800, Siva Velusamy wrote:
> In this thread:
> 
> http://sources.redhat.com/ml/gdb/2005-11/msg00251.html
> 
> Eli mentions that "If someone finds a way to announce a read
> watchpoint when the value changed on a target that supports that,
> without losing support for read watchpoints on x86 (which is by far
> the most popular platform these days), I'll gladly agree to such a
> change"

That sounds like what I was thinking of.

> So I guess the question really is if there has been an update to this.

Not that I know of.  We'd need some sort of way to say "read
watchpoints are not supported, emulate it with an access watchpoint
instead".

-- 
Daniel Jacobowitz
CodeSourcery

Re: rwatchpoint configuration

[Eli Zaretskii]

> Date: Mon, 17 Dec 2007 16:59:39 -0800
> From: "Siva Velusamy" <siva.velusamy@gmail.com>
> 
> In this thread:
> 
> http://sources.redhat.com/ml/gdb/2005-11/msg00251.html
> 
> Eli mentions that "If someone finds a way to announce a read
> watchpoint when the value changed on a target that supports that,
> without losing support for read watchpoints on x86 (which is by far
> the most popular platform these days), I'll gladly agree to such a
> change"
> 
> So I guess the question really is if there has been an update to this.

No, not that I know of.  I myself only work on x86, so I have no way
of proposing a tested solution.

Re: rwatchpoint configuration

[Eli Zaretskii]

> Date: Mon, 17 Dec 2007 16:59:39 -0800
> From: "Siva Velusamy" <siva.velusamy@gmail.com>
> 
> In this thread:
> 
> http://sources.redhat.com/ml/gdb/2005-11/msg00251.html
> 
> Eli mentions that "If someone finds a way to announce a read
> watchpoint when the value changed on a target that supports that,
> without losing support for read watchpoints on x86 (which is by far
> the most popular platform these days), I'll gladly agree to such a
> change"
> 
> So I guess the question really is if there has been an update to this.

For now, you could try a workaround: put two watchpoints on the same
expression: one an rwatch (the one you wanted), the other a write
watchpoint whose `commands' say just "continue".  This should cause GDB
to note the changed value when it is written into the variable(s), so
when the rwatch triggers it will see the known value and stop.

Please see if this works for you.  If it doesn't, please tell more
details.

Re: rwatchpoint configuration

[Siva Velusamy]

>
> For now, you could try a workaround: put two watchpoints on the same
> expression: one an rwatch (the one you wanted), the other a write
> watchpoint whose `commands' say just "continue".  This should cause GDB
> to note the changed value when it is written into the variable(s), so
> when the rwatch triggers it will see the known value and stop.
>
> Please see if this works for you.  If it doesn't, please tell more
> details.
>

This will probably sound like an ugly hack, but I ended up just
commenting out the logic that checks to see if the value has changed
in the case of a read breakpoint. So I bypass this issue at compile
time.

Setting an rwatch and a watch will work, but it wastes an additional
watchpoint resource (which is scarce on MicroBlaze). Plus gdb is being
used via Eclipse in this particular environment which would
necessitate changes in a bunch of other places to seamlessly do this.

My interaction with gdb code has been limited to minor target specific
bugfixes, so I probably do not understand all the ramifications to
propose a good solution. However, it seems to me that it should be
possible to make this check conditional at runtime based on some field
in current_target..say
current_target->target_supports_true_read_watchpoints.

-Siva

Re: rwatchpoint configuration

[Eli Zaretskii]

> Date: Mon, 17 Dec 2007 19:48:23 -0500
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb@sourceware.org
> 
> Eli, I think I remember you discussing this with someone else, a year
> or two ago; do you remember the reasoning?  If the watchpoint's type
> is "only trigger on reads", then core GDB assuming it triggers on all
> accesses seems problematic to me.

It is the best compromise so far, if you take into account that the
most popular platform needs the current behavior.  As I said back
then, if someone comes with a way to support true read watchpoints,
I'll happily accept such a change.