Most servers/clients should have xml support by now so it should behave
like `dp` in any other debugger. vFile is the only way to get detailed pid info unfortunately.
Execvp may hang until a signal is received on some systems(reproduced in
arch linux) in case the file can't be executed for some reason(broken
symlink, different arch, etc).
Previously, when using `dp=`, the debug plugin would set a new tid based
on the requested pid, but r_debug_select would set the old tid as dbg->tid,
resulting in issues interacting with the current thread. This could also
be an issue when the requested pid/tid is invalid and the plugin selects
something else.
Previously, `dp=` wouldn't fully switch to the given process since it was
treated like `dpt` thread switching, leaving the debugger in an undefined state.
Previously, the command didn't show the pid's path, replaced the path
field with current/ppid, and showed the ppid instead of only showing the
requested process and the children of the requested process.
opt->sz is initialized with r_buf_size at r_bin_open_io using an io
buffer if r_bin_open_io can't open a file buffer. Since the debuggers
returned unsigned values to opt->sz which is signed, opt->sz would
overflow and contain a negative value, causing r_bin_open_buf to fail.
Went ahead and modified CUR_END values for all debuggers even though this
should only affect remote debuggers. ST64_MAX should be enough.
With https://github.com/actions/labeler/issues/12
being an issue, the action's labeler is useless for PRs that come from a fork.
This one runs on a cron timer instead and doesn't suffer from the same issue.
Before we didn't check if a virtual address read/write would go through a page boundary. This fixes it.
Also do some formatting and re-enable some useful error messages
