mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2025-03-13 13:49:00 +08:00
39edd165f4
Nowadays, if user requests HW watchpoint to monitor a large memory area or unaligned area, aarch64 GDB will split into multiple aligned areas, and use multiple debugging registers to watch them. However, the registers are not updated in a transaction way. GDBserver doesn't revert updates in previous iterations if some debugging registers fail to update due to some reason, like no free debugging registers available, in the latter iteration. For example, if we have a char buf[34], and watch buf in gdb, (gdb) watch buf Hardware watchpoint 2: buf (gdb) c Continuing. infrun: clear_proceed_status_thread (Thread 13466) infrun: proceed (addr=0xffffffffffffffff, signal=GDB_SIGNAL_DEFAULT) infrun: step-over queue now empty infrun: resuming [Thread 13466] for step-over Sending packet: $m410838,22#35...Packet received: 00000000000000000000000000000000000000000000000000000000000000000000 infrun: skipping breakpoint: stepping past insn at: 0x400524 infrun: skipping breakpoint: stepping past insn at: 0x400524 Sending packet: $Z2,410838,22#80...Packet received: E01 <----- [1] Packet Z2 (write-watchpoint) is supported Sending packet: $Z0,7fb7fe0a8c,4#43...Packet received: OK Warning: Could not insert hardware watchpoint 2. Could not insert hardware breakpoints: You may have requested too many hardware breakpoints/watchpoints. GDB receives E01 for Z2 packet [1] but GDBserver updates the debugging register status, insert_point (addr=0x00410838, len=34, type=hw-write-watchpoint): BREAKPOINTs: BP0: addr=0x0, ctrl=0x00000000, ref.count=0 BP1: addr=0x0, ctrl=0x00000000, ref.count=0 BP2: addr=0x0, ctrl=0x00000000, ref.count=0 BP3: addr=0x0, ctrl=0x00000000, ref.count=0 BP4: addr=0x0, ctrl=0x00000000, ref.count=0 BP5: addr=0x0, ctrl=0x00000000, ref.count=0 WATCHPOINTs: WP0: addr=0x410850, ctrl=0x00001ff5, ref.count=1 WP1: addr=0x410848, ctrl=0x00001ff5, ref.count=1 WP2: addr=0x410840, ctrl=0x00001ff5, ref.count=1 WP3: addr=0x410838, ctrl=0x00001ff5, ref.count=1 four debugging registers can not monitor 34-byte long area, so the last iteration of updating debugging register state fails but previous iterations succeed. This makes GDB think no HW watchpoint is inserted but some debugging registers are used. This problem was exposed by "watch buf" gdb.base/watchpoint.exp with aarch64 GDBserver debugging arm 32-bit program. The buf is 30-byte long but 4-byte aligned, and four debugging registers can't cover 34-byte (extend 4 bytes to be 8-byte aligned) area. However, this problem does exist on non-multi-arch debugging scenario as well. This patch moves code in aarch64_linux_region_ok_for_hw_watchpoint to aarch64_linux_region_ok_for_watchpoint in nat/aarch64-linux-hw-point.c. Then, checks with aarch64_linux_region_ok_for_watchpoint, like what we are doing in GDB. If the region is OK, call aarch64_handle_watchpoint. Regression tested on aarch64 with both 64-bit program and 32-bit program. Some fails in gdb.base/watchpoint.exp are fixed. gdb: 2015-09-03 Yao Qi <yao.qi@linaro.org> * aarch64-linux-nat.c (aarch64_linux_region_ok_for_hw_watchpoint): Move code to aarch64_linux_region_ok_for_watchpoint. Call aarch64_linux_region_ok_for_watchpoint. * nat/aarch64-linux-hw-point.c (aarch64_linux_region_ok_for_watchpoint): New function. * nat/aarch64-linux-hw-point.h (aarch64_linux_region_ok_for_watchpoint): Declare it. gdb/gdbserver: 2015-09-03 Yao Qi <yao.qi@linaro.org> * linux-aarch64-low.c (aarch64_insert_point): Call aarch64_handle_watchpoint if aarch64_linux_region_ok_for_watchpoint returns true.
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.