Problem with "watch" on a new port.

Problem with "watch" on a new port.

[Florent DEFAY]

Hi,

I am working on a new port for a 16 bit machine.

step, stepi, next, nexti, breakpoints work well.
The problems come with "watch", it does not work :

(gdb) watch i
Hardware watchpoint 2: i
(gdb) c
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
0x00000174 in main () at main.c:67
67        for (i = 0; i < 10; i++)
(gdb) c
Continuing.
Program received signal SIGTRAP, Trace/breakpoint trap.
0x0000019c in main () at main.c:67
67        for (i = 0; i < 10; i++)
(gdb)


or


(gdb) watch results_16[0]
(gdb) c
Continuing.

and assignment of results_16[0] not detected.

I do not know where to begin to solve this problem.

Please, have you any clue?

Regards.

Florent

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

[Vladimir Prus]

Florent DEFAY wrote:

> Hi,
> 
> I am working on a new port for a 16 bit machine.
> 
> step, stepi, next, nexti, breakpoints work well.
> The problems come with "watch", it does not work :
> 
> (gdb) watch i
> Hardware watchpoint 2: i
> (gdb) c
> Continuing.
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x00000174 in main () at main.c:67
> 67        for (i = 0; i < 10; i++)

This suggest you did not define, or improperly defined, the
to_stopped_by_watchpoint or to_stopped_data_address or
to_watchpoint_address_withing_range target methods.

> (gdb) c
> Continuing.
> Program received signal SIGTRAP, Trace/breakpoint trap.
> 0x0000019c in main () at main.c:67
> 67        for (i = 0; i < 10; i++)
> (gdb)
> 
> 
> or
> 
> 
> (gdb) watch results_16[0]
> (gdb) c
> Continuing.
> 
> and assignment of results_16[0] not detected.

Is this variable actually modified *before* the execution leaves
the current scope?

- Volodya

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

[Florent DEFAY]

Thank you.

>This suggest you did not define, or improperly defined, the
>to_stopped_by_watchpoint or to_stopped_data_address or
>to_watchpoint_address_withing_range target methods.

I take inspiration from or1k and I do not find these target methods implemented.
I found them nowhere but in i386 arch, in i386-nat.c.
I do not understand the link between i386-nat.c and the t-dep file.
For my arch, I implemented a t-dep only. How to add a nat? Is it
really necessary?

>> and assignment of results_16[0] not detected.
>
>Is this variable actually modified *before* the execution leaves
>the current scope?

Yes it is.

Regards.

Florent

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

[Vladimir Prus]

On Thursday 02 July 2009 Florent DEFAY wrote:

> Thank you.
> 
> >This suggest you did not define, or improperly defined, the
> >to_stopped_by_watchpoint or to_stopped_data_address or
> >to_watchpoint_address_withing_range target methods.
> 
> I take inspiration from or1k and I do not find these target methods implemented.

I don't know what is or1k.

> I found them nowhere but in i386 arch, in i386-nat.c.

There's ppc_linux_stopped_by_watchpoint as well...

> I do not understand the link between i386-nat.c and the t-dep file.
> For my arch, I implemented a t-dep only. How to add a nat? Is it
> really necessary?

How are you debugging? Using remote connection? In that case, those methods
are not necessary, but your remote side should handle watchpoints per gdb
serial protocol docs. If you are gonna debug the program that is run on
the same system where GDB, you need to implement the methods I have mentioned.
 
> >> and assignment of results_16[0] not detected.
> >
> >Is this variable actually modified *before* the execution leaves
> >the current scope?
> 
> Yes it is.

Then, I can only guess that something outside gdb fails to notice the
watchpoint.

- Volodya

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

[Jeremy Bennett]

On Thu, 2009-07-02 at 17:10 +0200, Florent DEFAY wrote:

> >This suggest you did not define, or improperly defined, the
> >to_stopped_by_watchpoint or to_stopped_data_address or
> >to_watchpoint_address_withing_range target methods.
> 
> I take inspiration from or1k and I do not find these target methods implemented.
> I found them nowhere but in i386 arch, in i386-nat.c.
> I do not understand the link between i386-nat.c and the t-dep file.
> For my arch, I implemented a t-dep only. How to add a nat? Is it
> really necessary?

Hi Florent,

or1k (OpenRISC 1000) implements to_stopped_by_watchpoint and
to_stopped_data_address. You can find the functions
(or1k_stopped_by_watchpoint and or1k_stopped_data_address) in
remote-or1k.c of the OpenRISC GDB 6.8 distribution. These functions are
set up for the target in _initialize_remote_or1k.

The code is quite old (it's tidied up from the GDB 5.3 implementation)
using the proprietary OpenRISC Remote JTAG protocol. Since it is
primarily an embedded processor core, all the recent work on OpenRISC
1000 has been to use the GDB remote serial protocol (RSP), so
watchpoints are implemented on the server side as z2, z3, z4, Z2, Z3 and
Z4 packets.

HTH,


Jeremy

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

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

[Florent Defay]

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.

main.c
---------
void foo ()
{
}

int main ()
{
  int a = 1;
  int i;

  for (i = 0; i < 10; i++)
  {
    if (i == 5)
    {
      a = 2;
    }
  }

  for (i = 0; i < 10; i++)
  {
    if (i == 5)
    {
      foo();
      a = 3;
    }
  }

  return 0;
}
-----------------------------------------------------------


behavior 1
--------------
Breakpoint 1, main () at main.c:8
warning: Source file is more recent than executable.
8         int a = 1;
(gdb) watch a
Hardware watchpoint 2: a
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
main () at main.c:11
11        for (i = 0; i < 10; i++)
(gdb) p i
$1 = 5
(gdb) p a
$2 = 1
(gdb) c
Continuing.

Program received signal SIGTRAP, Trace/breakpoint trap.
main () at main.c:11
11        for (i = 0; i < 10; i++)
(gdb) p i
$3 = 5
(gdb) p a
$4 = 2
(gdb) c
Continuing.
//// nothing happens, infinite waiting
-----------------------------------------------------------

behavior 2
--------------
Breakpoint 1, main () at main.c:8
8         int a = 1;
(gdb) set can-use-hw-watchpoints 0
(gdb) watch a
Watchpoint 2: a
(gdb) c
Continuing.
Watchpoint 2: a

Old value = 2
New value = 1
main () at main.c:11
11        for (i = 0; i < 10; i++)
(gdb) c
Continuing.
Watchpoint 2: a

Old value = 1
New value = 2
main () at main.c:11
11        for (i = 0; i < 10; i++)
(gdb) p i
$1 = 5
(gdb) c
Continuing.

Watchpoint 2 deleted because the program has left the block in
which its expression is valid.
0x0000004e in foo () at main.c:4
4       }
-----------------------------------------------------------

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.

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).

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.

Thank you.

Regards,

Florent.

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

[Jeremy Bennett]

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