mirror of
https://github.com/radareorg/radare2.git
synced 2025-01-26 15:54:59 +00:00
594b940b7c
* Do not check with r_return_ if the convention is present Let's just assume the NULL default in such a case, so that architectures for which we don't have a defined calling convention can still be processed somehow by the analysis code. It won't be precise, but it's better than nothing. Also add a warning message so users are aware when the calling convention is not defined. * Fix oob-read when # is at the end of the cmd string * Do not set TMPDIR when the new value is the empty string When TMPDIR is set to empty value, clang+ld behaves in weird ways and you cannot compile files from within the r2 shell (e.g. when using #!c or #!cpipe) * Use meson and add -lasan to pkgconfig files when sanitizer are used
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?