mirror of
https://github.com/radareorg/radare2.git
synced 2025-02-03 20:22:38 +00:00
b20295c4ea
- Some minor hacks everywhere to glue - 'dr' command runs '|reg' io-ptrace command (reg dbg stuff needs more work) - '|reg' is a temporal command that prints x86-ptrace-linux registers * Added debug visual print mode using && :) - 's' key steps in debugger * Added m and ' keys in visual (mark and goto mark) like in vim or r1 :) - store/use seek addresses * Make use of the cmd.prompt and cmd.vprompt magic * Added debug handlers list with 'dh' - dh ptrace called at init - dp pid called at init too (hacky style) * Added debug->wait method for the debug handlers * Add 'fb' command to set base for flags * Fix flag redefinition (f foo && f foo @ 33) now works * Added s64 type (signed 64 bit integer) * Fixed && and '"' special chars in commnad parsing --HG-- rename : libr/debug/p/ptrace.c => libr/debug/p/dbg-ptrace.c
r_debug
=======
Debugger API for radare2
We need to connect multiple pieces...
debugger engine: vm, qemu, bochs, ptrace, mach, w32dbg...
controlflow commands: (should be splitted in two layers)
- continue -- low level
- step -- low level
- trace --- high level one
- ...
the control flow commands depend on other stuff to decide
how to work..this is for example if the arch doesnt supports
continuation, we should provide a step based continue. The
same when a watchpoint is activated and the arch didnt
supports hardware regs for this purpose.
We also need a load/store/dump/restore functions to move the
program from one engine to another (ptrace -> qemu).. we should
provide a way for all this operations between them.
[continue]
|--- check if bp api allows us to continue or we should step into..
|--- check if debug plugin supports continue
[getregs]
|--- r_reg give us a list of registers
| - dr (show bitsize debug registers) // 32 by default
| - dr 32 (show 32 bit debug registers) // depends on size
| - dr eax (show 'eax' register value)
| - dr al (show 8bit register 'al')
| - dr eax=33 (set 'eax' register value)