ARM: list number of HW breakpoints/watchpoints

When starting up, say how many hardware breakpoints and watchpoints
are available on various targets.

This makes it easier to tell GDB how many of those resources exist.
Its remote protocol currently has no way to ask OpenOCD for that
information, so it must configured by hand (or not at all).

Update the docs to mention this; remove obsolete "don't do this" info.
Presentation of GDB setup information is still a mess, but at least
it calls out the three components that need setup.

Signed-off-by: David Brownell <dbrownell@users.sourceforge.net>

diff --git a/doc/openocd.texi b/doc/openocd.texi
index ef395ea2b444eaea1e1c6ca97734a059f25e8faa..a83c966b302bb816317e93938c6bd090fcecbfab 100644 (file)
--- a/doc/openocd.texi
+++ b/doc/openocd.texi
@@ -6497,6 +6497,21 @@ a bit of googling to find something that fits your requirements.
 @cindex GDB
 OpenOCD complies with the remote gdbserver protocol, and as such can be used
 to debug remote targets.
+Setting up GDB to work with OpenOCD can involve several components:
+
+@itemize
+@item OpenOCD itself may need to be configured.  @xref{GDB Configuration}.
+@item GDB itself may need configuration, as shown in this chapter.
+@item If you have a GUI environment like Eclipse,
+that also will probably need to be configured.
+@end itemize
+
+Of course, the version of GDB you use will need to be one which has
+been built to know about the target CPU you're using.  It's probably
+part of the tool chain you're using.  For example, if you are doing
+cross-development for ARM on an x86 PC, instead of using the native
+x86 @command{gdb} command you might use @command{arm-none-eabi-gdb}
+if that's the tool chain used to compile your code.
 
 @anchor{Connecting to GDB}
 @section Connecting to GDB
@@ -6528,19 +6543,34 @@ session.
 To list the available OpenOCD commands type @command{monitor help} on the
 GDB command line.
 
+@section Configuring GDB for OpenOCD
+
 OpenOCD supports the gdb @option{qSupported} packet, this enables information
 to be sent by the GDB remote server (i.e. OpenOCD) to GDB. Typical information includes
 packet size and the device's memory map.
+You do not need to configure the packet size by hand,
+and the relevant parts of the memory map should be automatically
+set up when you declare (NOR) flash banks.
+
+However, there are other things which GDB can't currently query.
+You may need to set those up by hand.
+As OpenOCD starts up, you will often see a line reporting
+something like:
 
-Previous versions of OpenOCD required the following GDB options to increase
-the packet size and speed up GDB communication:
 @example
-set remote memory-write-packet-size 1024
-set remote memory-write-packet-size fixed
-set remote memory-read-packet-size 1024
-set remote memory-read-packet-size fixed
+Info : lm3s.cpu: hardware has 6 breakpoints, 4 watchpoints
 @end example
-This is now handled in the @option{qSupported} PacketSize and should not be required.
+
+You can pass that information to GDB with these commands:
+
+@example
+set remote hardware-breakpoint-limit 6
+set remote hardware-watchpoint-limit 4
+@end example
+
+With that particular hardware (Cortex-M3) the hardware breakpoints
+only work for code running from flash memory.  Most other ARM systems
+do not have such restrictions.
 
 @section Programming using GDB
 @cindex Programming using GDB

diff --git a/src/target/cortex_m3.c b/src/target/cortex_m3.c
index 558b2117b446e777a39256d3ae687ca8450577a9..bdd323349fbc99cf91b41e2df05c87b2530bb55b 100644 (file)
--- a/src/target/cortex_m3.c
+++ b/src/target/cortex_m3.c
@@ -1608,6 +1608,12 @@ static int cortex_m3_examine(struct target *target)
 
                /* Setup DWT */
                cortex_m3_dwt_setup(cortex_m3, target);
+
+               /* These hardware breakpoints only work for code in flash! */
+               LOG_INFO("%s: hardware has %d breakpoints, %d watchpoints",
+                               target_name(target),
+                               cortex_m3->fp_num_code,
+                               cortex_m3->dwt_num_comp);
        }
 
        return ERROR_OK;

diff --git a/src/target/embeddedice.c b/src/target/embeddedice.c
index cca9cc06269a3281c468aa8e3297d64d215d6b92..eb04bd12ed74c4d307212eaf1d213c2fc43e1294 100644 (file)
--- a/src/target/embeddedice.c
+++ b/src/target/embeddedice.c
@@ -289,6 +289,9 @@ embeddedice_build_reg_cache(struct target *target, struct arm7_9_common *arm7_9)
                                buf_get_u32(reg_list[EICE_COMMS_CTRL].value, 0, 32));
        }
 
+       LOG_INFO("%s: hardware has 2 breakpoints or watchpoints",
+                       target_name(target));
+
        return reg_cache;
 }
 

diff --git a/src/target/xscale.c b/src/target/xscale.c
index ac697da9e7e2a9bf53efff7660c1dfcf3178a8a8..9ed9eea2ab9a04bb1caabc1fa5de707f22f9a824 100644 (file)
--- a/src/target/xscale.c
+++ b/src/target/xscale.c
@@ -2970,6 +2970,9 @@ static int xscale_init_arch_info(struct target *target,
        xscale->dbr0_used = 0;
        xscale->dbr1_used = 0;
 
+       LOG_INFO("%s: hardware has 2 breakpoints and 2 watchpoints",
+                       target_name(target));
+
        xscale->arm_bkpt = ARMV5_BKPT(0x0);
        xscale->thumb_bkpt = ARMV5_T_BKPT(0x0) & 0xffff;