| 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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
This is vaguely competent at tracing single-threaded programs. Vi-like
keybinds defined in misplays.c.
Signed-off-by: Malfurious <m@lfurio.us>
|
