Reputation: 836
The gdb python API defines the gdb.BP_BREAKPOINT
flag to use when creating a gdb.Breakpoint
object, but there doesn't seem to be a flag that allows a hardware breakpoint to be set? Am I missing something?
I'd like to create a gdb.Breakpoint
object so that I can override the stop
method and react to breakpoints as they're triggered. As far as I can tell, there isn't a way to do this otherwise.
Interestingly enough, if I set a breakpoint the 'normal' way (eg, break *0x400123
), then gdb.breakpoints()
returns an object. However, if I set a hardware breakpoint the same way (hbreak *0x400123
), no objects are returned. This seems to indicate that the python API can't access/manipulate HW breakpoints directly?
Using GDB 8.3.50.20190824-30.fc31 on Fedora 31.
Upvotes: 1
Views: 431
Reputation: 2897
I had this same problem recently. I found a hacky workaround to force gdb to use hardware breakpoints.
There's the gdb auto-hw
setting, that lets gdb decide whether to insert hardware or software breakpoints automatically. This setting should be on by default.
If gdb isn't able to set a software breakpoint because the memory region is not writable, it will insert a hardware breakpoint. You can define a non-writable memory region by issuing the mem
command.
mem 0 0xffffffffffffffff ro
And then your script can create all the breakpoints it wants :) (well, at least all the breakpoints the processor allows it to create)
After the breakpoints are inserted, you can go back to normal memory regions by doing mem auto
.
This issue has been recently solved. So we can expect it will be available in a future release of gdb :)
Upvotes: 1
Reputation: 836
Haven't found a way to do this using the gdb.Breakpoint
, but I've got a workaround instead.
offset = 0x400123
gdb.execute("hbreak *" + hex(offset))
while True:
gdb.execute("continue")
value = int(gdb.parse_and_eval("$pc"))
if value == offset:
# respond to hardware breakpoint here
else:
# something else happened??
It's not perfect, but meets my current needs.
Upvotes: 0