This is an archive of the discontinued LLVM Phabricator instance.

Add support for importing general C++ modules into the LLDB expression evaluator
Needs ReviewPublic

Authored by teemperor on May 6 2019, 12:16 PM.

Details

Reviewers
aprantl
shafik
Summary

This patch adds basic support for importing C++ modules in general into the LLDB expression evaluator. It mostly reuses
the code we already use for the std module prototype for building/importing the modules, but is using a different logic
for querying the modules from the executable. The current functionality is limited - like the first std module patch - to
only reading module information but not merging or substituting debug information.

Unlike the std module prototype, this feature now requires that we compile with -gmodules, as this is the only way we
have all modules (even modules that were just imported but not actually used) in the debug information. Without this,
we run into frequent build errors as soon as some module includes another module without actually using it. This leads
to the situation where Clang will not emit the module in the debug information (as it's unused), but LLDB will fail to
compile the C++ module as it still needs the include paths of the unused module. This is why we now have a
GetAllUsedModules that works similar to GetImportedModules but actually creates a complete list of all modules we
have used in a given compilation unit. This allows LLDB to fully reconstruct the original include directories.

Diff Detail

Event Timeline

teemperor created this revision.May 6 2019, 12:16 PM
Herald added a project: Restricted Project. · View Herald TranscriptMay 6 2019, 12:16 PM
aprantl added inline comments.May 7 2019, 9:54 AM
lldb/include/lldb/Symbol/CompileUnit.h
397

All *Clang/Source* modules? Otherwise it sounds like lldb::Modules.

lldb/source/Plugins/ExpressionParser/Clang/ClangUserExpression.cpp
486

std::copy_if?

lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
933

Is that a bug in Clang? Can you send me an example?

934

That is not the only valid name for module map files, we also support module.map, module.private.modulemap and possibly more. I feel like there should be a better solution to the underlying problem.

995

This sounds wrong for LTO binaries, which will contain many Clang CUs in one file.