The debugger, like the compiler, is a complex piece of software where bugs are inevitable. When a bug is reported, one of the first steps in its life cycle is trying reproduce the problem. Given the number of moving parts in the debugger, this can be quite challenging. Especially for more sophisticated problems, a small changes in the environment, the binary, its dependencies, or debug information might hide the problem. Getting this right puts a heavy burden on both the reporter and the developer.
Reproducers are a way to automate this process. They contains the necessary information for a bug to occur again with minimal interaction from the developer. For clang a reproducer consists of a script with the compiler invocation and a pre-processed source file. Doing the same thing for the debugger is much more complicated.
This talk discusses what was needed to have working reproducers for LLDB. It goes into detail about what information was needed, how it was captured and finally how the debugger uses it to reproduce an issue. The high level design is addressed as well as some of the challenges, such as dealing with low-level details, remote debugging, and the SB API. It concludes with an overview of what is possible and what isn't.
