Hello members,

Now I've noticed that GDB always tries to use hardware watchpoints
while remote debugging, even the target doesn't have the hardware
watchpoint support.  

-----
$ ./gdb hello_target
GNU gdb 6.6.50.20070904-cvs
Copyright (C) 2007 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 "--host=i686-pc-linux-gnu --target=powerpc64-linux"...
(gdb) set solib-absolute-prefix /target/sysroot
(gdb) target remote remote_server:2015
Remote debugging using remote_server:2015
0x0ffd6bf4 in _start () from /target/sysroot/lib/ld.so.1
(gdb) set debug remote 1
(gdb) watch glob
Sending packet: $m10010b30,4#84...Ack
Packet received: 00000003
Hardware watchpoint 1: glob
(gdb) c
Continuing.
Sending packet: $Z0,ffcf654,4#4a...Ack
Packet received:
Packet Z0 (software-breakpoint) is NOT supported
Sending packet: $mffcf654,4#01...Ack
Packet received: 893a0000
Sending packet: $Xffcf654,0:#22...Ack
Packet received: OK
binary downloading suppported by target
Sending packet: $Xffcf654,4:}]\202\020\b#9a...Ack
Packet received: OK
Sending packet: $m10010b30,4#84...Ack
Packet received: 00000003
Sending packet: $Z2,10010b30,4#cf...Ack
Packet received:
Packet Z2 (write-watchpoint) is NOT supported
warning: Could not remove hardware watchpoint 1.
Warning:
Could not insert hardware watchpoint 1.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.

(gdb)
------

GDB decides which type of watchpoints should be set when giving the
command like "watch foo".  And hardware watchpoints can be used when
gdbserver has the Z-packet support.  However, as the session log above
has shown, GDB does not check the Z-packet support on gdbserver when
deciding the type of the watchpoint but when actually setting the
watchpoint to the target.  

It has a simple workaround for this problem: delete the watchpoint and
setting "remote hardware-watchpoint-limit" to 0, and set it again.
But I thought that the timing when checking the Z-packet support
should be fxied and made a fix for this as attached.  
The concept is:

- gdbserver: Allows "Z#" packets (not "Z#,addr,length").  
             Responds "OK" if hardware breakpoints/watchpoints are
             supported or responds "".  

- gdb:       Sends a "Z#" packet for checking if hardware
             breakpoints/watchpoints can be handled on the target.  


And two things which I feel indecisive for this fix are there:

- I defined a new function pointer "watchpoint_support" in target_ops
  for gdbserver, because I thought we cannot decide the common address
  value for all the architectures supported by gdbserver at which we
  should not set a hardware watchpoint.  If we can, we can use the
  existing format of Z-packet for this purpose.  

- The newly defined packet format might cause problems like exceptions
  or setting a hardware watchpoint at the unexpected location when
  working with older versions of gdbserver, because in which the
  Z-packet format is not checked at all.  The codes in CVS head are
  below:


    case 'Z':
      {
        char *lenptr;
        char *dataptr;
        CORE_ADDR addr = strtoul (&own_buf[3], &lenptr, 16);
        int len = strtol (lenptr + 1, &dataptr, 16);
        char type = own_buf[1];

        if (the_target->insert_watchpoint == NULL
            || (type < '2' || type > '4'))
          {
            /* No watchpoint support or not a watchpoint command;
               unrecognized either way.  */
            own_buf[0] = '\0';
          }
        else
          {
            int res;

            res = (*the_target->insert_watchpoint) (type, addr, len);
            if (res == 0)
              write_ok (own_buf);
            else if (res == 1)
              /* Unsupported.  */
              own_buf[0] = '\0';
            else
              write_enn (own_buf);
          }
        break;
      }


Would anyone give me any comments how it should be treated as a whole?
Defines another packet for it?  Applies as proposed and notes "it
might not work with older versions of gdbserver" ?


By the way, now I have *finally* got the copyright assignment for FSF.
But the problem I have addressed for the first time here has already
fixed by Luis Machado and many active members in the list.  I would
like to thank all of them, and apologize for not giving enough
comments for it.  


Best regards,
-- 
Emi SUZUKI / emi-suzuki at tjsys.co.jp