Software watchpoint breakage on SuperH

Software watchpoint breakage on SuperH

[Paul Mundt]

[-- Attachment #1: Type: text/plain, Size: 2995 bytes --]

There seems to be a bit of weirdness happening with software watchpoints on
SuperH. Namely, the watchpoint gets deleted on any kind of function call -- in
this case, printf(). I've run this test on both x86 and sh (both on a Solution
Engine 7709 and a Solution Engine 7750 .. SH-3/4 respectively), and the x86
seems to perform the way it should.

Both of these tests were run with ELF lazy binding disabled via
LD_BIND_NOW=true.

When running on x86, I see the following:

(gdb) set can-use-hw-watchpoints 0
(gdb) l
1	int main()
2	{
3		int i;
4	
5		for (i = 0; i < 10; i++)
6			;
7	
8		printf("%d\n", i);
9	
10		return 0;
(gdb) b 5
Breakpoint 1 at 0x8048466: file watchtest.c, line 5.
(gdb) b 8
Breakpoint 2 at 0x8048480: file watchtest.c, line 8.
(gdb) r
Starting program: /home/paulm/./watchtest 

Breakpoint 1, main () at watchtest.c:5
5		for (i = 0; i < 10; i++)
(gdb) watch i > 5
Watchpoint 3: i > 5
(gdb) c
Continuing.
Watchpoint 3: i > 5

Old value = 1
New value = 0
0x0804846e in main () at watchtest.c:5
5		for (i = 0; i < 10; i++)
(gdb) c
Continuing.
Watchpoint 3: i > 5

Old value = 0
New value = 1
0x0804847d in main () at watchtest.c:5
5		for (i = 0; i < 10; i++)
(gdb) c
Continuing.

Breakpoint 2, main () at watchtest.c:8
8		printf("%d\n", i);
(gdb) c
Continuing.
10

Watchpoint 3 deleted because the program has left the block in
which its expression is valid.
0x08048499 in main () at watchtest.c:11
11	}
(gdb) c
Continuing.

Program exited normally.
(gdb) 

which all looks fine. But when running on SuperH, I get the following:

(gdb) b 5
Breakpoint 1 at 0x4004a8: file watchtest.c, line 5.
(gdb) b 8
Breakpoint 2 at 0x4004e0: file watchtest.c, line 8.
(gdb) r
Starting program: /tmp/./watchtest

Breakpoint 1, main () at watchtest.c:5
5               for (i = 0; i < 10; i++)
(gdb) watch i > 5
Watchpoint 3: i > 5
(gdb) c
Continuing.
Watchpoint 3: i > 5

Old value = 1
New value = 0
0x004004ac in main () at watchtest.c:5
5               for (i = 0; i < 10; i++)
(gdb) c
Continuing.
Watchpoint 3: i > 5

Old value = 0
New value = 1
0x004004c6 in main () at watchtest.c:5
5               for (i = 0; i < 10; i++)
(gdb) c
Continuing.

Breakpoint 2, main () at watchtest.c:8
8               printf("%d\n", i);
(gdb) c
Continuing.

Watchpoint 3 deleted because the program has left the block in
which its expression is valid.
printf (format=0x4005dc "%d\n") at printf.c:33
33      printf.c: No such file or directory.
	in printf.c
(gdb) c
Continuing.
10

Program exited normally.
(gdb) 

Everything looks fine up until the point it tries to do the printf().

Is there something that needs to be implemented per target to support software
watchpoints properly? If not, does anyone have any suggestions as to what
could be going wrong in the above, and better yet, suggestions for possible
fixes?

Regards,

-- 
Paul Mundt <lethal@chaoticdreams.org>


[-- Attachment #2: Type: application/pgp-signature, Size: 240 bytes --]

Re: Software watchpoint breakage on SuperH

[Eli Zaretskii]

On Thu, 6 Jun 2002, Paul Mundt wrote:

> Watchpoint 3 deleted because the program has left the block in
> which its expression is valid.
> printf (format=3D0x4005dc "%d\n") at printf.c:33
> 33      printf.c: No such file or directory.
> 	in printf.c
> (gdb) c
> Continuing.
> 10
> 
> Program exited normally.
> (gdb)=20
> 
> Everything looks fine up until the point it tries to do the printf().
> 
> Is there something that needs to be implemented per target to support softw=
> are
> watchpoints properly? If not, does anyone have any suggestions as to what
> could be going wrong in the above, and better yet, suggestions for possible
> fixes?

It's not necessarily a problem with watchpoint support.  It could be that 
GDB cannot reliably detect where the current value of PC belong, so it 
mistakenly reports it's inside printf while in fact it's after `main' 
returns.

Another possibility is that the code which determines the current stack 
frame is faulty (that's the code GDB runs to know whether the watchpoint 
is in scope).