Watchpoints in an ARM platform

Hi,

I was experimenting with gdb 6.6 on an ARM device and I
noticed a
problem with watchpoints. I was using a simple application I
compiled
with a cross-compiler like this:

$ arm-none-linux-gnueabi-gcc testgdb.c -g3 -O0 -Wall
-fno-omit-frame-pointer -o testgdb --sysroot /tftpboot/ltib

Here is a gdb session to better show you the problem:

$ gdb ./testgdb
GNU gdb 6.6
Copyright (C) 2006 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public
License, and you are
welcome to change it and/or distribute copies of it under
certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show
warranty" for details.
This GDB was configured as
"arm-none-linux-gnueabi"...
Using host libthread_db library
"/lib/libthread_db.so.1".
(gdb) b Dummy1
Breakpoint 1 at 0x8390: file testgdb.c, line 6.
(gdb) r
Starting program: /testgdb
Hello World!

Breakpoint 1, Dummy1 () at testgdb.c:6
6               for(i=0; i<10 ; i++)
(gdb) l 6
1       #include <stdio.h>
2
3       void Dummy1()
4       {
5               int i;
6               for(i=0; i<10 ; i++)
7               {
8                       printf("itteration
%dn",i);
9               }
10      }
(gdb) rwatch i
Target does not support this type of hardware watchpoint.
(gdb) awatch i
Target does not support this type of hardware watchpoint.
(gdb) watch i
Watchpoint 2: i
(gdb) c
Continuing.
Watchpoint 2: i

Old value = 33480
New value = 0
0x00008398 in Dummy1 () at testgdb.c:6
6               for(i=0; i<10 ; i++)
(gdb) c
Continuing.

Watchpoint 2 deleted because the program has left the block
in
which its expression is valid.
0x0000828c in ?? ()
(gdb) n
Cannot find bounds of current function
(gdb)
Cannot find bounds of current function
(gdb) q
The program is running.  Exit anyway? (y or n) y
$

It says the target doesn't support that type of hardware
watchpoint
when I've tried rwatch and awatch, but it works when I use
the watch
command (maybe using some software watchpoint). After that I
can
continue and it correctly stops the program the first time,
but when I
continue again something goes wrong and gdb gets confused.
Do you have
any idea why this happens? Am I missing anything here?

Best regards,

-- Ulisses

On Thu, May 31, 2007 at 12:18:32PM +0200, Ulisses Furquim
wrote:
> It says the target doesn't support that type of
hardware watchpoint
> when I've tried rwatch and awatch, but it works when I
use the watch
> command (maybe using some software watchpoint). After
that I can

Correct.  ARM Linux has no support for hardware watchpoints;
I don't
think any ARM platform has watchpoints that can be used in
user space
like i386 / ppc do.  It might be possible to expose the
same
watchpoint controller that JTAG would use though.

> continue and it correctly stops the program the first
time, but when I
> continue again something goes wrong and gdb gets
confused. Do you have
> any idea why this happens? Am I missing anything here?

A software watchpoint is implemented by repeatedly single
stepping.
You've stepped into something that confused GDB, probably
the start of
a PLT stub for a function from a dynamic library.  I thought
recent
ARM GDB would recognize those stubs fine, but I guess
something has
gone wrong.

-- 
Daniel Jacobowitz
CodeSourcery

Hi Daniel,

On 5/31/07, Daniel Jacobowitz <drowfalse.org> wrote:
> Correct.  ARM Linux has no support for hardware
watchpoints; I don't
> think any ARM platform has watchpoints that can be used
in user space
> like i386 / ppc do.  It might be possible to expose the
same
> watchpoint controller that JTAG would use though.

Ok, thanks.

> > continue and it correctly stops the program the
first time, but when I
> > continue again something goes wrong and gdb gets
confused. Do you have
> > any idea why this happens? Am I missing anything
here?
>
> A software watchpoint is implemented by repeatedly
single stepping.
> You've stepped into something that confused GDB,
probably the start of
> a PLT stub for a function from a dynamic library.  I
thought recent
> ARM GDB would recognize those stubs fine, but I guess
something has
> gone wrong.

Hmm.. a function from a dynamic library? Are you sure? I had
only a
simple loop where variable "i" was incremented and
then I was printing
something.

Regards,

-- Ulisses