| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
On completion of an initial single step, we can and should discard these
breakpoints, even though the thread may not be "stopping" and go on to
continue in free-run. They have served their purpose at this point and
we would like to avoid any other thread encountering them.
Also, whenever uninstall_breakpoints() is called, it is because we are
cycling a process's threads and are about to run resume_threads() which
currently does the work of re-computing a thread's step breakpoints if a
previous single step was interrupted, whether or not the step
breakpoints for that instant have already been figured. So this also
addresses a bug where one thread, with repeatedly interrupted single
steps, would accumulate more and more redundant breakpoint entries until
it was finally able to proceed and eventually stop.
Signed-off-by: Matt Hunter <m@lfurio.us>
|
|
A stopped thread should sometimes restart, even if a breakpoint
interrupted a single step. detect_breakpoint() and its interaction with
wait_thread() is updated such that any restart during a single step
scenario properly "requeues" the thread's run intent, by preserving the
doing/donext flags.
Furthermore, detect_breakpoint() ditches its call to get_breakpoint()
and considers any and all breakpoints impacting the current thread PC,
since they may each suggest different restarting requirements. In
effect, the thread will only remain stopped if at least one relevant
breakpoint allows it to do so.
This reverts commit 5589a9e3afd5 ("Ignore breakpoints during
singlestep").
Signed-off-by: Matt Hunter <m@lfurio.us>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
