In contrast, LLDB can import Clang modules explicitly built by the build system directly, without needing to recompile them from source code. By skipping the module compilation in the debugger, this can be much faster.
Migrating to an explicitly built module system is part of our plan and we are very much looking forward to it, but it seems challenging given the build time concerns(Build times regression with Explicitly Built Modules) and the current WIP state of its support in the Bazel ecosystem. With these challenges in mind, I’m curious if some of the stages or optimizations performed in the explicit module system - particularly those that enhance debugger performance - could be adapted or leveraged within the implicit module build system, addressing developer immediate concerns as well as giving us some buffer to migrate to explicitly built modules feature to get other benefits.
For instance, since .o files in the implicit system already reference .pcm files,
- is there a way for LLDB to utilize these
.pcmfiles directly instead of recompiling modules from source? - Alternatively, could the build system emit
.pcmfiles into a shared cache that LLDB can access, (assuming its not happening today or for some reason the cache is being invalidated for some reason, if yes, any tooling that can help identify why the cache is being invalidated would be valuable) - Could the work that LLDB performs to build the expression context across debug sessions be cached in some way to improve performance? (relevant components as some components would be invalidated given devs iteration)