- For the functionality added to address #10283, we need to wait until we
receive the Team listener's thread state change notification before submitting
the report generation request, else the thread might not actually be stopped
yet when the generator walks the thread list. Should fix some lingering issues
with stack traces sometimes not being returned when using this mode of
operation.
- When constructing the CLI interface, also pass along the target thread ID
if one was specified.
- If our only reason for starting is to save a report, and we've been given
a specific thread to target, rather than just a team, ensure that the target
thread is in a stopped state prior to saving the report.
- Added 'frame' command for setting/printing the context's current stack
frame within the active stack trace.
- Added 'variables' command for printing the list of variables visible
within the current frame.
- CommandLineUserInterface is now a team listener. Consequently, when asked
to generate a debug report on startup without running the input loop,
it now waits for receipt of the debug report event to terminate.
- Style fixes.
- When invoked, starts up the CLI such that it bypasses waiting for
input and instead save a crash report of the running team, then exits.
Mainly intended to be used by debug_server.
* "thread": prints/sets the current thread.
* "continue", "stop": continue/stop the current thread.
* "sc"/"bt": Print a stack trace for the current thread. Very basic yet.
* Introduce the notion of a current thread. That's the one certain
commands will target (by default).
* Add more event handling in CliContext. There's now a queue of pending
events which are printed in the input loop at convenient times to
inform the user about what happened (new/deleted/stopped threads,
etc.).
* Move the libedit interface there and provide nicer to use methods.
* Also start adding utility methods for the input loop. It is going to
manage all interactions of the input loop with outside events.
* Fix the "quit" command. The user is now prompted what to do with the
debugged team and the input loop thread avoids reentering the input
loop.
* UserInterface::SynchronouslyAskUser() is now allowed to return -1 to
indicate that the user cannot be asked at this point for whatever
reason. The caller needs to handle that case.
* UserInterfaceListener::UserInterfaceQuitRequested(): Add new parameter
"quitOption" to specify what is supposed to happen. The previous
behavior (ask user) is only one of the options. The others are to kill
the debugged team or to resume it.
There's an input loop thread which reads and parses command lines and
the infrastructure for registering and executing commands. Currently
only "help" and "quit" commands are implemented.
Rene Gollent