Hello LLVM and Dexter Community,
I present to you the 'Debugger Controller' patch.
Recently there's been interest in running the debugger frame work of Dexter in new and interesting ways. My own work coupled with the work of some other Dexter contributors has highlighted an issue:
The current architecture of Dexter doesn't support new and novel ways of running the debugger. If one wishes to write their own debugger running behaviour, that behaviour has to sit awkwardly with the existing behaviour. But fear not, this patch goes some of the way to fixing this issue.
The original implementation of DebuggerBase was a monolith of 3 things - It's responsible for exposing the features of the debuggers (good), operating the debuggers behaviour to get step information (bad) and responsible for archiving and generating said step behaviour (also bad).
This patch addresses behaviour 2. The operating behaviour of the debugger has been promoted to a first class object, the DebuggerController. If you wish to implement your own debugger operating behaviour simply inherit from DebuggerControllerBase and extend the _run_debugger_custom method.
Also rolled in with this patch is how the debugger controller, context, options and step collections are passed around Dexter. No longer is the get_debugger_steps method in Debuggers.py responsible be passing context, options or step collections to the internal_run_debugger_ tool. It's job now is to pass a fully formed debugger controller object that contains all the information required to run the debugger. Context, Options and step information are all stored in the DefaultController now (which represents the default dexter behaviour before this patch). As a result, get_debugger_steps is now known as run_debugger_subprocess as that is all it's responsible for.
We now pass the controller as a pickled object, unpickle and run it in the internal tool and then repickle to be returned back to run_debugger_subprocess, this is then returned to the caller of run_debugger_subprocess. This could be the test tool, the clang-opt-bisect tool or any other tool that exists within dexter. Which debugger controller is passed is up to us as developers, so we can pick and choose for whatever case suits our needs.
A follow up patch for this change is also incoming that will have a new type of debugger controller, the ConditionalSteppingController. In order to bring this new behaviour to dexter it's paramount that we have an extensible debugger operating architecture, and it's my hope that this patch delivers on this premise.