2009-02-05 21:08:46 +00: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
|
2010-01-21 01:38:52 +00:00
|
|
|
- r_debug can handle the remoteness of the debugger backend.
|
|
|
|
- r_io can do it also
|
|
|
|
- Watchpoints and its exception should be handled here
|
2009-02-05 21:08:46 +00:00
|
|
|
- watchpoint expressions should be handled by using the r_num stuff
|
2010-01-21 01:38:52 +00:00
|
|
|
- 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.
|
2009-02-05 21:08:46 +00:00
|
|
|
|
|
|
|
* Do we need the plugin API to define new breakpoints and so on?
|