]> git.ipfire.org Git - thirdparty/binutils-gdb.git/commit
[regression] Do not read from catchpoint/watchpoint locations' addresses when checkin...
authorLuis Machado <lgustavo@codesourcery.com>
Wed, 12 Aug 2015 08:52:50 +0000 (05:52 -0300)
committerLuis Machado <lgustavo@codesourcery.com>
Wed, 12 Aug 2015 08:52:50 +0000 (05:52 -0300)
commit835001623351330d49678d215d1338c0ce35c1f9
tree0ca5573abea0e7a384ae3f5cb046508fe590defe
parent948601f7d9d5f8976b5f139f42b5c656d0743f3c
[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.
gdb/ChangeLog
gdb/breakpoint.c