| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
ARM 32-bit is the first platform added to misplays which lacks
underlying hardware support for single step traps - so the kernel does
not implement PTRACE_SINGLESTEP in this case.
We will work around this in a similar way as gdb does and how the kernel
used to do it until 2011. arm_singlestep() implements logic which
disassembles the program's current instruction and analyzes it to
determine all possible next locations - eg: the next instruction in
memory, or the jump target of a branch instruction, etc. This logic is
dynamically dispatched by the debugger core if an ARM build is running
in 32-bit mode.
arm_singlestep() uses breakpoints to stop execution at it's computed
next locations. However, misplays is currently very careful about
controling the use of breakpoints in order to avoid issues with thread
single steps - so a new flag (called "step") is added to breakpoints to
enable the debugger to selectively install this subset of breakpoints
for each thread's single step action, and more or less keep treating
thread free-run as normal. install_breakpoints() is updated to take a
"step" parameter to control which set of breakpoints is installed at any
given time.
resume_threads() is updated to perform this new single step dynamic
dispatch, and manage the installation of step breakpoints.
add_breakpoint() is also given a "step" parameter. This initializes the
flag for the new breakpoint, but crucially is used to sort the new
breakpoint into the process breakpoint list. Since step breakpoints
will always be installed first, prioritize them in the list so that
uninstall_breakpoints() doesn't corrupt memory when it runs the list
backward to remove them.
Signed-off-by: Matt Hunter <m@lfurio.us>
|
|
Signed-off-by: Matt Hunter <m@lfurio.us>
|
|
Signed-off-by: Matt Hunter <m@lfurio.us>
|
|
If dbg_attach fails, it calls this function to clean up before the
process in added to the main process list, so list_remove() is invalid.
Signed-off-by: Matt Hunter <m@lfurio.us>
|
|
Previously, the test UI logic would constantly regenerate and print the
screen's contents every iteration of the main processing loop to naively
ensure that changes to the underlying system were reflected immediately.
Sometimes, this would result in a screen flicker due to the rapid
clearing and printing.
This makes the UI a bit smarter about when refreshes occur, by
monitoring activity results from the debugger and console modules in
addition to user input. This should improve the screen flicker
performance.
This also addresses an issue selecting text on the screen, which was
previously not possible due to the rapid refreshing as well.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Abstract architecture details into architecture.h and add x86 constants.
This is slightly complicated by the fact that 64-bit hosts can run
32-bit code, so we do still need to resolve some values dynamically.
The architecture_info() function is intented to address this, and
performs parameter lookups based on the current state of the guest
process.
Resolving values on a per-process-state basis is important due to the
process model under Linux. If we fork to debug a 32-bit program, the
forked process will be native 64-bit until the execve system call. And
of course, the process is then free to exec anything it likes later on
as well.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
I don't think this is strictly necessary, just seemed like a good idea.
However, this function doesn't seem to be available on my test ARM
system, so it is removed for compatibility.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Add list functions which can efficiently cut down on some bolierplate.
The rest of the code will eventually be cleaned to make use of them.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
This bug would occur when the debugger keeps rapidly hitting a
breakpoint and restarting execution (and the breakpoint is temporary /
one-time). For example, stepping over a long recursive call.
It would be possible for the user to manually interrupt execution at the
precise moment that the debugee was returning from a single step over
the breakpoint. In this scenario, the thread would correctly remain
stopped as requested, however the temporary breakpoint would incorrectly
remain in the breakpoint list. The cause of this issue is that
uninstall_breakpoints only considered removing temporaries if they were
currently installed for use.
This makes sense, as we have used the b->installed flag as a sort of
check to see if we have YET installed the breakpoint (rather than "is it
STILL installed?") to ensure that we don't remove it too soon.
The more accurate logic here is to acctually check whether the
breakpoint has EVER been installed and only then consider it for removal
if it is temporary. This fixes the case in question without breaking
behavior when performing an initial run single step.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Display the value of active breakpoint threads, target stack frames, and
enable status.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
This branch adds initial support for multithreaded targets, as well as
forking and exec syscalls. All of the bugs from initial testing are
fixed so far.
* threads: (25 commits)
Don't spin waiting to interrupt zombie process
Allow termination and exec events to propagate immediately
Implement support for PTRACE_EVENT_FORK and ui
Handle PTRACE_EVENT_EXIT to capture a final state snapshot
Detect out-of-band thread exec state changes to prevent deadlock
Enable user creation of thread-specific breakpoints
Add orig_rax to register display
Tweak SCHEDULER_DELAY for use with installing breakpoints
Ignore breakpoints during singlestep
Fix bug with cleaning temporary breakpoints
Independent thread control refactor
Multithread version 3
Add strict_strtoul
Prevent lingering traps after detach
Handle PTRACE_EVENT_EXEC
Workaround SIGSTOP on child process startup
setpgid is redundant with setsid and causes an error
Display name of pending signal
dbg_realcont for testing purposes
Display installed status of breakpoints
...
|
|
Targets can get into this state, for example, when receiving a killing
signal.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Also, it is now possible for interrupt_all_threads to fail to stop
threads in uninterruptable sleep (eg: the main thread during execve).
This may happen in more general cases as well, but it is now common
enough in that case to worry about.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Due to new independent thread control, it is now possible and likely
that breakpoints will be installed before singlesteps are waited upon to
be completed.
also clean detect_breakpoint with get_breakpoint.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
dont remove them before initial use
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
There can sometimes be a pending SIGTRAP when we resume a thread. This
is usually due to interrupting a hung single-step. If this trap is hit
after the debugger leaves, the original process will crash. This is a
quick workaround to attempt to consume such traps ourselves before
detaching.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
The debugger design prefers to use PTRACE_SEIZE instead of
PTRACE_ATTACH, due to the simpler thread control semantics that are
available.
However, to utilize the same featureset for forked processes, we can no
longer use PTRACE_TRACEME to guarantee that the child becomes a tracee
before it execs into the target program.
Manually raising SIGSTOP to act as a synchronization point is
problematic for a couple reasons:
- We need to detect whether the special SIGSTOP was or was not yet
encountered by the time our debugger module attaches and
interrupts the thread. This complicates the dance of input
controls to ensure we are at the exec (and nowhere else) when the
real user takes over the controls.
- The injection of an extra signal circumvents the benefits we hope
to leverage by using the PTRACE_SEIZE semantics. We can no longer
assume that all incoming signals are genuine.
For the time being, sleep in the newly forked child for the scheduler
delay period. This is not bullet-proof, but tends to allow the debugger
module enough time to actually seize the thread before anything
interesting happens. At this point a single dbg_cont() will cause the
child to arrive and stop at the user's exec.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
We need to perform these changes with a thread ID that is known to be in
ptrace stop. This is a requirement of the API even though the memory
change is seen by all threads of the guest process.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Use `th->state == NULL` as an indicator that each thread's state is
capturable, discard use of the `all` parameter.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
This is vaguely competent at tracing single-threaded programs. Vi-like
keybinds defined in misplays.c.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
* Bring-your-own-node (generic / zero allocations)
* Doubly-linked and circular, forward and backward traversable
* Random insert/removal in constant time
* All operations are no-fail
* [Some type safety concessions though]
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Abort on allocation failure. This is mostly done as a formality, as
Linux tends to over-commit memory anyway. In the event of most
failures, we won't have a reasonable recovery either.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
This is good enough for early testing of the debugger functionality, but
should be improved in the future.
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
|
Signed-off-by: Malfurious <m@lfurio.us>
|
