This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Use LLVM's implementation of AppleTables for apple_{names,namespaces}
ClosedPublic

Authored by fdeazeve on Jun 27 2023, 5:55 AM.

Details

Summary

All the new code should match the behavior of the old exactly.

Of note, the custom queries used to be implemented inside HashedNameToDIE.cpp
(which is the LLDB implementation of the tables). However, when porting to LLVM,
we believe they don't belong inside the LLVM table implementation:

  1. They don't require any knowledge about the table itself
  2. They are not relevant for other users of these classes.
  3. They use LLDB data structures.

As such, we implement these custom queries inside AppleDWARFIndex.cpp.

Types and Objective-C tables are done separately, as they have slightly
different functionality that require rewriting more code.

Diff Detail

Event Timeline

fdeazeve created this revision.Jun 27 2023, 5:55 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 27 2023, 5:55 AM
Herald added a subscriber: arphaman. · View Herald Transcript
fdeazeve requested review of this revision.Jun 27 2023, 5:55 AM
Herald added a project: Restricted Project. · View Herald TranscriptJun 27 2023, 5:55 AM
fdeazeve updated this revision to Diff 534951.Jun 27 2023, 6:09 AM

Improve comments

fdeazeve added inline comments.Jun 27 2023, 6:11 AM
lldb/source/Plugins/SymbolFile/DWARF/AppleDWARFIndex.cpp
228

In case you are thinking: "This method doesn't make any sense!", you are right.

This is called "GetFunctions" but doesn't return only functions, callers are expected to check if the DIE is a function or not. I thought about changing this, but didn't want to add any behavior changes in the patch.

JDevlieghere accepted this revision.Jun 27 2023, 11:23 AM

LGTM, regardless of whether you decided the tackle the the DataExtractor issue. If you don't I would still encourage you to update/simplify/rephrase the comment.

lldb/source/Plugins/SymbolFile/DWARF/AppleDWARFIndex.cpp
26–29

I was a little confused by this comment. IIUC we cannot pass debug_str.getAsLLVM() to the AppleAcceleratorTable because it takes the DataExtractor by value and that would cause slicing. But why is that a problem though? A DWARFDataExtractor is a DataExtractor so wouldn't that be fine?

Alternatively, should we have another getAsLLVM() helper that returns a DataExtractor (and rename the current one to something like getAsLLVMDWARF).

228

👍

This revision is now accepted and ready to land.Jun 27 2023, 11:23 AM
fdeazeve added inline comments.Jun 27 2023, 12:37 PM
lldb/source/Plugins/SymbolFile/DWARF/AppleDWARFIndex.cpp
26–29

IIUC we cannot pass

Your understanding is correct!

A DWARFDataExtractor is a DataExtractor so wouldn't that be fine?

Slicing isn't inherently bad, so long as the Derived constructor doesn't change the Base class in a way that leaves it in an invalid state after slicing. Does DWARFDataExtractor respect that? I honestly don't know, but even if it did, this is not future-proof.

Alternatively, should we have another getAsLLVM() helper that returns a DataExtractor (and rename the current one to something like getAsLLVMDWARF).

I like this idea, let me give it a try in a separate patch

fdeazeve updated this revision to Diff 535155.Jun 27 2023, 3:18 PM

Rebase after addressing the extractor issue in a separate patch: D153913

fdeazeve updated this revision to Diff 535160.Jun 27 2023, 3:28 PM

Fix rebase issue