aboutsummaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorLuis Machado <lgustavo@codesourcery.com>2015-08-12 05:36:09 -0300
committerLuis Machado <lgustavo@codesourcery.com>2015-08-12 05:36:09 -0300
commit244558af868d5427903c35c5105bf5499639f81f (patch)
tree4d837e5976c06fc18f619815cf393d2f7a5f9330
parent0eace2105dc6c005fdc908414ad564d318b71540 (diff)
downloadgdb-244558af868d5427903c35c5105bf5499639f81f.zip
gdb-244558af868d5427903c35c5105bf5499639f81f.tar.gz
gdb-244558af868d5427903c35c5105bf5499639f81f.tar.bz2
[regression] Do not read from catchpoint/watchpoint locations' addresses when checking for a permanent breakpoint
While running bare-metal tests with GDB i noticed some failures in gdb.base/break.exp, related to the use of the catch commands. It turns out GDB tries to access memory address 0x0 whenever one tries to insert a catchpoint, which should obviously not happen. This was introduced with the changes for permanent breakpoints. In special, bp_loc_is_permanent tries to check if there is a breakpoint inserted at the same address as the current breakpoint's location's address. In the case of catchpoints, this is 0x0. (top-gdb) catch fork Sending packet: $m0,1#fa...Packet received: E01 Catchpoint 4 (fork) (top-gdb) catch vfork Sending packet: $m0,1#fa...Packet received: E01 Catchpoint 5 (vfork) It is not obvious to detect because this fails silently for Linux. For our bare-metal testing, though, this fails with a clear error message from the target about not being able to read such address. The attached patch addresses this by bailing out of bp_loc_is_permanent (...) if the location address is not meaningful. I also took the opportunity to update the comment for breakpoint_address_is_meaningful, which mentioned breakpoint addresses as opposed to their locations' addresses. gdb/ChangeLog: 2015-08-11 Luis Machado <lgustavo@codesourcery.com> * breakpoint.c (bp_loc_is_permanent): Return 0 when breakpoint location address is not meaningful. (breakpoint_address_is_meaningful): Update comment.
-rw-r--r--gdb/ChangeLog6
-rw-r--r--gdb/breakpoint.c17
2 files changed, 18 insertions, 5 deletions
diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 01e9938..4d60123 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,9 @@
+2015-08-12 Luis Machado <lgustavo@codesourcery.com>
+
+ * breakpoint.c (bp_loc_is_permanent): Return 0 when breakpoint
+ location address is not meaningful.
+ (breakpoint_address_is_meaningful): Update comment.
+
2015-08-11 Keith Seitz <keiths@redhat.com>
* NEWS: Mention explicit locations.
diff --git a/gdb/breakpoint.c b/gdb/breakpoint.c
index bffff23..a6994c7 100644
--- a/gdb/breakpoint.c
+++ b/gdb/breakpoint.c
@@ -6963,14 +6963,14 @@ describe_other_breakpoints (struct gdbarch *gdbarch,
/* Return true iff it is meaningful to use the address member of
- BPT. For some breakpoint types, the address member is irrelevant
- and it makes no sense to attempt to compare it to other addresses
- (or use it for any other purpose either).
+ BPT locations. For some breakpoint types, the locations' address members
+ are irrelevant and it makes no sense to attempt to compare them to other
+ addresses (or use them for any other purpose either).
More specifically, each of the following breakpoint types will
- always have a zero valued address and we don't want to mark
+ always have a zero valued location address and we don't want to mark
breakpoints of any of these types to be a duplicate of an actual
- breakpoint at address zero:
+ breakpoint location at address zero:
bp_watchpoint
bp_catchpoint
@@ -9007,6 +9007,13 @@ bp_loc_is_permanent (struct bp_location *loc)
gdb_assert (loc != NULL);
+ /* If we have a catchpoint or a watchpoint, just return 0. We should not
+ attempt to read from the addresses the locations of these breakpoint types
+ point to. program_breakpoint_here_p, below, will attempt to read
+ memory. */
+ if (!breakpoint_address_is_meaningful (loc->owner))
+ return 0;
+
cleanup = save_current_space_and_thread ();
switch_to_program_space_and_thread (loc->pspace);