[Bug breakpoints/9794] New: Define and implement a RSP query packet for hardware breakpoint count.

["anmol at freescale dot com" <sourceware-bugzilla at sourceware dot org>]

It would be nice if: When GDB remote connects; there were a q-packet for the 
 target stub to communicate back to GDB the number of hardware break/watchpoints 
 it supports, so that GDB automatically sets hardware-breakpoint-limit. I think
 it would be of help to the user (rather than letting the user run into an error
 situation when more than the target supported hardware break/watch-points are
 attempted to be set).

 Currently GDB allows as many harware breakpoints to be set.

------------------------------------------------------------------
(gdb) hbreak gdb.c:131
Hardware assisted breakpoint 1 at 0x200037a8: file
/proj/.ppc_07/labhome/b07584/hv-hw-bkpts/test/gdb/gdb.c, line 131.
(gdb) hbreak gdb.c:132
Hardware assisted breakpoint 2 at 0x200037ac: file
/proj/.ppc_07/labhome/b07584/hv-hw-bkpts/test/gdb/gdb.c, line 132.
(gdb) hbreak gdb.c:133
Hardware assisted breakpoint 3 at 0x200037b4: file
/proj/.ppc_07/labhome/b07584/hv-hw-bkpts/test/gdb/gdb.c, line 133.
(gdb) hbreak gdb.c:134
Hardware assisted breakpoint 4 at 0x20003804: file
/proj/.ppc_07/labhome/b07584/hv-hw-bkpts/test/gdb/gdb.c, line 134.
(gdb) hbreak gdb.c:135
Hardware assisted breakpoint 5 at 0x200037e0: file
/proj/.ppc_07/labhome/b07584/hv-hw-bkpts/test/gdb/gdb.c, line 135.
------------------------------------------------------------------
 
 And upon a continue:

------------------------------------------------------------------
(gdb) c
Continuing.
Warning:
Cannot insert hardware breakpoint 3.
Cannot insert hardware breakpoint 4.
Cannot insert hardware breakpoint 5.
Could not insert hardware breakpoints:
You may have requested too many hardware breakpoints/watchpoints.
-----------------------------------------------------------------

 It would be more beneficial to the user to not allow more than the
 target supported harware break/watch-point count to be set? (Or at
 least to change the above error message to specify how many).

 IRC discussion with daney:
 --------------------------

--------------------------------------------------------------------------------
anmol Hello, Is there a q-packet which will allow GDB to query how many hardware
breakpoints are supported by a stub? (So that hardware-breakpoint-limit could be
set automatically when GDB remote connects to a stub). Sorry if this is
documented somewhere - I did try to look but could not find it in the GDB User
Manual. Thanks, Anmol.
daney anmol: As far as I know gdb doesn't have a concept of how many hardware
breakpoints a target supports.  This is a deficiency in IMHO.
daney You can add many hardware watches.  You only get an error when you run (or
continue) with too many enabled.
daney This based on my hacking on mips watch register support.
anmol Thanks Daney; I know, and that might be a little confusing for the user. I
see that once the HW bkpt limit (i.e. as defined by the target) is hit - then it
keeps saying it cannot insert any more - once we delete them so that w are back
to being within limits - things work again. 
anmol I was wondering if it would be worth it to define a q packet that lets GDB
query the target i.e. have the stub send back this info when GDB remote connects
so that when we do a show remote harware-breakpoint-limit - the user knows.
--------------------------------------------------------------------------------

 GDB Guru's, Please let me know your valuable thoughts and suggestions - I would
 like to attempt to fix this. Thanks.

-- 
           Summary: Define and implement a RSP query packet for hardware
                    breakpoint count.
           Product: gdb
           Version: 6.8
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: breakpoints
        AssignedTo: anmol at freescale dot com
        ReportedBy: anmol at freescale dot com
                CC: gdb-prs at sourceware dot org


http://sourceware.org/bugzilla/show_bug.cgi?id=9794

------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.