Re: Problem with "watch" on a new port.

[Jeremy Bennett <jeremy dot bennett at embecosm dot com>]

On Tue, 2009-07-07 at 14:28 +0200, Florent Defay wrote:
> Hi,
> Thank you very much to all for the answers.
> 
> I am still in trouble with the "watch" issue.
> 
> I give you a concrete example of the problem bellow.
> I debug main.c with the target-gdb (remote protocol) in two different ways.

Hi Florent,

I think some of these issues are down to the OpenRISC 1000 simulator,
not GDB.

<detailed code example deleted>

> 
> My conclusion :
> In behavior 1, Hardware watchpoint is used. The problem is
> 1- There are no info about old and new value.
> 2- The statement a = 3; is not detected.

I've looked in the code for the OpenRISC 1000 simulator. Hardware
watchpoints are not supported in the RSP interface. They return an empty
packet, which *should* cause GDB to realise they are not supported and
use software watchpoints.

I think this is generic, so it should not require any architecture
specific functionality.

So I don't understand why this is not working correctly, and reporting a
hardware watchpoint being set. It is possible it relies on an aspect of
the architecture (in or1k-tdep.c), which has not been implemented. Or it
could be a bug in GDB - have you checked Bugzilla?

> In behavior 2, Software watchpoint is used. The problem is
> 1- It cannot be a final solution because it is very slow.
> 2- "Watchpoint 2 deleted because the program has left the block in
> which its expression is valid."
> is not a good behavior. The call to foo has a secondary unexpected
> effect (it is the same behavior every time a function is called).

I would expect the first example to behave like this as well. If RSP
reports HW watchpoints are not available, a SW watchpoint should be
used.

I'm not an expert on watchpoints. I don't know why you get the report
about the watchpoint being deleted. I would not expect the watchpoint to
be deleted until after the program has left it's last loop in main().

However. Is this optimized code? It's quite possible that foo has been
inlined. In which case this report may actually be referring correctly
to the end of the second loop (which would be the same address in the
compiled code).

Possibly others on this group can advise more on how software
watchpoints are handled.

> The simulator (sid) seems to receive Z/z packets well. It may be due
> to a mistake in t-dep or something missing but I do not know what.
> Plus, step, next, breakpoints, finish work very well.

HTH,


Jeremy

-- 
Tel:      +44 (1590) 610184
Cell:     +44 (7970) 676050
SkypeID: jeremybennett
Email:   jeremy.bennett@embecosm.com
Web:     www.embecosm.com