radare2/libr/bp
2018-06-03 18:47:58 +02:00
..
p Fix #10241 - Modified ARM32 breakpoint, this may break other ARM cpus... 2018-06-03 18:47:58 +02:00
bp_io.c Add drx_add/delete for watchpoint (#8244) 2017-08-20 10:39:10 +02:00
bp_plugin.c Fix oob read with dbh- command 2017-04-18 19:07:14 +02:00
bp_traptrace.c Add sys/sdk build script (wip) 2017-02-02 13:25:14 +01:00
bp_watch.c Add conditional watchpoint (#8321) 2017-08-26 18:57:51 +02:00
bp.c Add initial temp breakpoint support (#9845) 2018-04-15 00:36:40 +02:00
Makefile Add sys/sdk build script (wip) 2017-02-02 13:25:14 +01:00
meson.build [WIP] Move hardcoded paths to r_userconf.h (#9959) 2018-04-28 10:02:55 +02:00
README * Initial working implementation of software breakpoints 2010-01-21 02:38:52 +01:00

libr.bp
=======

Breakpoint API

- Manages list of defined breakpoints
- Determines if a stop is caused by a breakpoint
- Owns a database of multiple types of breakpoints
  - arch and os based ones
  - Supports endianness
  - r_bp_get should return a buffer and a length
- Manages conditional breakpoints expressions
- Types of breakpoints
  - software (traps)
  - conditional traps
  - hardware (registers)
  - mmu (changes page protections)
- All non-native operations are translated into evaluable expressions
  by other modules. Like changing register values and so on
  - Do we should place some callbacks for this kind of ops?
- We need to make this work also remotely
  - r_debug can handle the remoteness of the debugger backend.
  - r_io can do it also
- Watchpoints and its exception should be handled here
  - watchpoint expressions should be handled by using the r_num stuff
- Hardware breakpoints require access to registers, or pid/tid
  this is... the debugger backend. For those, the debugger backend
  should fill a callback to manage them.
  - if the debugger breakpoint handler does not manages the breakpoint
    type, r_bp must do it with r_io storing and loading bp bytes.

* Do we need the plugin API to define new breakpoints and so on?