Skip to content

[lldb][SymbolFileDWARF] Don't search for DWP files on macOS #139554

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 1 commit into from
May 29, 2025
Merged

[lldb][SymbolFileDWARF] Don't search for DWP files on macOS #139554

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
3 changes: 3 additions & 0 deletions lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -4211,6 +4211,9 @@ SymbolFileDWARFDebugMap *SymbolFileDWARF::GetDebugMapSymfile() {

const std::shared_ptr<SymbolFileDWARFDwo> &SymbolFileDWARF::GetDwpSymbolFile() {
llvm::call_once(m_dwp_symfile_once_flag, [this]() {
if (m_objfile_sp->GetArchitecture().GetTriple().isAppleMachO())
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should this be a check for the ObjectFile subclass instead?

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@JDevlieghere Maybe you have a better layering suggestion?

Copy link
Member Author

@Michael137 Michael137 May 12, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That was my first inclination. But then I was reading the discussion at #139170 (comment) and was going to see where that goes before adding one of these kinds of APIs to ObjectFile

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah, this sounds like very much a dual problem to that, so it would be nice if they used the same approach. The thing that makes this fuzzier is that in this case you can't really say that SymbolFileDWARF requires ObjectFileMachO (or any other) because one can imagine a setup where someone knows they will only ever need to debug DWARF+ELF and so they want to strip out all of the other object file plugins. OTOH, I can also imagine us saying we don't want to support that. :P

Copy link
Member Author

@Michael137 Michael137 May 19, 2025 •
edited
Loading

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not sure what the resolution was re. the plugin dependencies discussion. Are we find with the current approach?

you can't really say that SymbolFileDWARF requires ObjectFileMachO (or any other) because one can imagine a setup where someone knows they will only ever need to debug DWARF+ELF and so they want to strip out all of the other object file plugins.

Good question. If we don't want to restrict a use-case such as the one you describe, I'm happy to add a SupportsDWP API to ObjectFile. Any thoughts @JDevlieghere ?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this is a good solution until we've documented the dependency policy from #139170

return;

// Create a list of files to try and append .dwp to.
FileSpecList symfiles;
// Append the module's object file path.
Expand Down
Loading