espressif/binutils-gdb
1
0
Fork 0
mirror of https://github.com/espressif/binutils-gdb.git synced 2025-06-23 03:29:47 +08:00
Code Issues Packages Projects Releases Wiki Activity

[regression] Do not read from catchpoint/watchpoint locations' addresses when checking for a permanent breakpoint

Browse Source 
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.
This commit is contained in:
Luis Machado
2015-08-12 05:36:09 -03:00
parent 0eace2105d
commit 244558af86
2 changed files with 18 additions and 5 deletions
Download Patch File Download Diff File Expand all files Collapse all files

6
gdb/ChangeLog
View File

@ -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> 2015-08-11 Keith Seitz <keiths@redhat.com>
* NEWS: Mention explicit locations. * NEWS: Mention explicit locations.

17
gdb/breakpoint.c
View File

@ -6963,14 +6963,14 @@ describe_other_breakpoints (struct gdbarch *gdbarch,
/* Return true iff it is meaningful to use the address member of /* Return true iff it is meaningful to use the address member of
BPT. For some breakpoint types, the address member is irrelevant BPT locations. For some breakpoint types, the locations' address members
and it makes no sense to attempt to compare it to other addresses are irrelevant and it makes no sense to attempt to compare them to other
(or use it for any other purpose either). addresses (or use them for any other purpose either).
More specifically, each of the following breakpoint types will 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 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_watchpoint
bp_catchpoint bp_catchpoint
@ -9007,6 +9007,13 @@ bp_loc_is_permanent (struct bp_location *loc)
gdb_assert (loc != NULL); 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 (); cleanup = save_current_space_and_thread ();
switch_to_program_space_and_thread (loc->pspace); switch_to_program_space_and_thread (loc->pspace);