This is an archive of the discontinued LLVM Phabricator instance.

Explicitly pass a module to register Xcode SDKs with to ParseXcodeSDK. Was: Add an API that allows iterating over a debug map's OSO's Modules
ClosedPublic

Authored by aprantl on May 4 2020, 6:38 PM.

Details

Summary

Based on Pavel's feedback, here is a different approach, where the "master" debug map module is passed in explicitly to ParseXcodeSDK(). This allows updating both the source remapping dictionary of the OSO (needed for source listings) and the debug map (needed to remap Clang compiler options in swift-lldb).

For Swift LLDB (but potentially also for module support in Clang-land) I need a way to accumulate the path remappings produced by Module::RegisterXcodeSDK(). Unfortunately there is no way to go from an executable's Module to the auxiliary modules that represent the individual OSO object files of a SymbolFileDWARFDebugMap.

Here is a proposed API that would allow me to do this. Does this look reasonable?

Diff Detail

Event Timeline

aprantl created this revision.May 4 2020, 6:38 PM
labath added a subscriber: labath.May 5 2020, 4:00 AM

My understanding is that these OSO modules are supposed to be a hidden implementation detail of SymbolFileDWARF(DebugMap) and that they should not leak out the main module. For example, we make sure to always rewrite any addresses that come out of the oso modules to be in terms of the main module, and ensure that parsed dwarf compile units are assigned to the CompileUnits belonging to the main module, etc.

In that world, the right thing to do would be to ensure that SymbolFileDWARF(DebugMap) accumulates the appropriate sdk information in the main module.

aprantl updated this revision to Diff 262208.May 5 2020, 1:30 PM

Completely different implementation :-)

aprantl retitled this revision from RFC: Add an API that allows iterating over a debug map's OSO's Modules to Explicitly pass a module to register Xcode SDKs with to ParseXcodeSDK. Was: Add an API that allows iterating over a debug map's OSO's Modules.May 5 2020, 1:33 PM
aprantl edited the summary of this revision. (Show Details)
labath added a comment.May 6 2020, 1:15 AM

Well... this is closer, but we should get rid of the Module argument. It's not consistent with the other SymbolFile functions, and also not necessary...

lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
782–791

I don't think you need to pass thread the Module argument everywhere. The module you want should be available as comp_unit.GetModule(). SymbolFileDWARFDebugMap::ParseCompileUnitAtIndex ensures that the CUs are created pointing to the "main" module.

Thanks, Pavel that was really helpful! Using cu->GetModule() indeed works, and is of course much cleaner.

This revision was not accepted when it landed; it landed in state Needs Review.May 6 2020, 5:04 PM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptMay 6 2020, 5:04 PM