* kvm_openfiles can fail so make sure we print the error message.
On OpenBSD you can use the kvm interface without /dev/kmem access but on FreeBSD
you need root or kmem access which one do not want to give a user.
Look at ps(1) on FreeBSD and see how they do it.
Note that OpenBSD can have mappings with zero size so relax the assert.
Also note that the protection bits are flipped. Different bit order. Will fix that later.
* Add support for dp and dp* on OpenBSD.
kvm_getprocs exists on Net and Free as well so it might work there as well
* Cosmetic changes after feedback. Thanks.
A TRAP signal signifes expected stops for breakpoints and so on. There's no
need to display these as signals or stops since they will be communicated
inside r_debug_bp_hit.
Linux kernel checks for unknown flags passed via the last argument to
waitpid() and fails waitpid() with EINVAL if it encounters one:
From kernel/exit.c:sys_wait4()
if (options & ~(WNOHANG|WUNTRACED|WCONTINUED|
__WNOTHREAD|__WCLONE|__WALL))
return -EINVAL;
This makes it impossible to use debugger on Linux.
WAIT_ANY macro is actually supposed to be used as PID argument to wait
for all children without specifying particular PID.
Signed-off-by: Pavel Borzenkov <pavel.borzenkov@gmail.com>
The major contribution here is completely re-worked breakpoint hit/recoil
handling. This work fixes#4907 and lays the ground work for future native
debugger improvements (multi-threading, etc).
* Give a human friendly type to enums
* Change many wait functions to return RDebugReasonType
* Better return checking (from r_debug_reg_sync, r_bp_restore)
* Optimized register synchronization
* Lots of comments and whitespace changes
* Improved inferior death detection
Handle EXIT_PID events differently than DEAD process events
* Move breakpoint/recoil handling to wait/cont/step
Rather than handing breakpoint related things inside cmd_debug.c, do that
inside the r_debug API functions. This seems like the most logical place for it
to live since it should apply to just about any platform/architecture. This
also centralizes calling into "cmd.bp" handling via the CoreBind callback.
* Track how the caller wishes to continue
It turns out that handling break point recoils is very complicated. The ptrace
API on Linux returns SIGTRAP for just about every type of operation (not just
breakpoints getting hit). Add the "recoil_mode" flag to indicate whether we are
single-stepping or continuing and whether or not we are inside the recoil.
* Proper handling for swstep=true
Since r_debug_step_soft calls r_debug_continue, it's already hitting the recoil
case there. Move the recoil handling from r_debug_step to r_debug_step_hard
only.
For the swstep=true case, special handling is required inside r_debug_recoil.
By resetting all of the breakpoints except the one we just hit, we ensure we
can step the original instruction and hit the new swstep breakpoint. Add a new
bp function called r_bp_restore_except to do this.
To make matters worse, we cannot use a BreakpointItem pointer because that
leads to a use-after-free condition. Instead, we the breakpoint address
instead.
Now breakpoints should work regardless of the swtep setting.
* Always call the recoil before continuing
Some callers of r_debug_continue might not have ever inserted any breakpoints
before. If we don't restore breakpoints before each call to the underlying
continue we won't hit them.
* Hide software step breakpoint events from the user
When a breakpoint even happens due to a software-step, hide it from the user.
They aren't really breakpoints as far as they are concerned.
* Improve process exit handling on Linux
There are three types of process exiting events on Linux:
1. PTRACE_EVENT_EXIT occurs just before a process exits. It's not possible to
prevent it from exiting, but it can be used to inspect the pre-exit state.
2. The process can exit for a variety of reasons and we can notice when we call
waitpid(2).
3. The process could die randomly on us :-/
On Windows, h->wait will return R_DEBUG_REASON_EXIT_PID, but it's more likely
on Linux to find out the process is already dead.
* Check more bits within waitpid status
We can often make a decision about what happened strictly by looking at the
status returned from waitpid. In other cases, we need to call
r_debug_handle_signals.
If we reach the end of this function without knowing what happened, consider it
an error.
Linux 2.5.46 made changes to the ptrace(2) API to inform a tracer when various
events occur. These are known as PTRACE_EVENTs. Start handling PTRACE_EVENTs
by:
* Handling PTRACE_EVENT_FORK and PTRACE_EVENT_EXIT
* For _FORK, stores the newly created pid in dbg->forked_pid
* Add the "dpc" command to select the most recently forked child process.
* Add the "dpc*" command to show the recently forked process' pid.
Additional minor changes to white space are included.
NOTE: This partially addresses #3549. It does handleLinux before 2.5.46.
* Fixes#4875: Refactor process listing
* Move procfs-based process listing into linux_debug.c, guarded by __linux__
* Provide a warning and eprintf a TODO on the remaining platforms.
* Break reusable parts into linux_get_proc_pid and call it as needed.
* Add/remove comments for clarity
* Address feedback and re-enable non-Linux
* http://man7.org/linux/man-pages/man5/core.5.html
* Able to dump the header and the program headers
* Checks /proc/[pid]/coredump_filter to know which maps should be dumped
* Check for bit 6 to 0 (priv/share anon mappings, priv/share file-backed, elf hdr, priv/share huge pages)
* Missing: priv/share DAX pages
instead of a thread waiting for incoming messages, i've implemented
wait functionality above mach_msg, now i have to make it work
with r2 and avoid while (1) in the code, understand better the
references and start thinking about edge cases
some rework in order to handle mach message as mach_exc_server and alike does
api change in plugin debug, now the function detach receive a pointer to RDebug
trying to deallocate port when are not needed any more
* use set_trace_bit and clear_trace_bit macros
* use PT_ATTACHEXC since PT_ATTACH will be deprecated in the future
and we are interested in receiving mach exceptions
* first attempt to handle mach exceptions
* api change: added a parameter to r_core_setup_debugger
at least in OS X this function was producing double attachment.
I've added a boolean value to indicate when use dpa.
* added pipe to communicate between main process and traced process
by far this is not a good implementation. We should develop a better
approach/design to save all the exceptions and handle them accordingly.
This is the initial implementation
* bring back ptrace for stability and in order to merge this into master
