| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
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>
|
