Some of you might have seen one or more of the logging related patches I put up for review over the past week. Originally I had meant for this to be a relatively simple change to add support for logging to a circular buffer. This quickly grew bigger than I had anticipated and currently the stack consists of 6 patches with a few more in flight. I try to keep the patches small to make reviewing easy, but that can make it harder to see the bigger picture. I figured this would be the best place to put all the pieces together.
Last year I outlined a new direction for the reproducers. Simply put, I want to be able to gather diagnostic information when LLDB runs into an issue or crashes. A big part of that are logs.
LLDB has a rich logging system. Often we can diagnose an issue based on the logs alone. However, the downside of such extensive logging is that it (1) generates a lot of output and (2) is prohibitively expensive to have enabled on all the time. I think we can identify a subset of the logs that would be still be useful while being cheap enough to collect all the time. When an issue occurs or when LLDB crashes, we would dump these “always-on” logs to a file and ask our users to attach them to a bug report. Best case scenario these logs are enough for us to diagnose the issue. Worst case they help us determine which (full) logs to ask for.
So how does that relate to the aforementioned patches? They’re building the foundation for always-on logging. I started with the concept of a log handler which allows us to customize where log messages are written to. Particularly relevant is the rotating log handler, which enables logging to an in-memory circular buffer. Next on the list is adding support for always-on logging itself and dumping the circular buffer to disk when we crash. Finally, we need to identify the subset of log messages to enable by default. I expect that this will be hardest part, but luckily this is something that we can do incrementally.