This is an archive of the discontinued LLVM Phabricator instance.

[lldb] Add a display name to ClangASTContext instances
ClosedPublic

Authored by teemperor on Jan 8 2020, 3:28 AM.

Details

Summary

I often struggle to understand what exactly LLDB is doing by looking at our expression evaluation logging as our messages look like this:

CompleteTagDecl[2] on (ASTContext*)0x7ff31f01d240 Completing (TagDecl*)0x7ff31f01d568 named DeclName1

From the log messages it's unclear what this ASTContext is. Is it the scratch context, the expression context, some decl vendor context or a context from a module?
The pointer value isn't helpful for anyone unless I'm in a debugger where I could inspect the memory at the address. But even with a debugger it's not easy to
figure out what this ASTContext is without having deeper understanding about all the different ASTContext instances in LLDB (e.g., valid SourceLocation
from the file system usually means that this is the Objective-C decl vendor, a file name from multiple expressions is probably the scratch context, etc.).

This patch adds a name field to ClangASTContext instances that we can use to store a name which can be used for logging and debugging. With this
our log messages now look like this:

CompleteTagDecl[2] on scratch ASTContext. Completing (TagDecl*)0x7ff31f01d568 named Foo

We can now also just print a ClangASTContext from the debugger and see a useful name in the m_display_name field, e.g.

m_display_name = "AST for /Users/user/test/main.o";

Diff Detail

Event Timeline

teemperor created this revision.Jan 8 2020, 3:28 AM
Herald added a project: Restricted Project. · View Herald TranscriptJan 8 2020, 3:28 AM

I don't know if this needs a unit test where we call the constructor and explicitly check the name is the one we passed in. Let me know if you think this would make sense.

labath added a comment.Jan 8 2020, 3:46 AM

Seems reasonable to me, some other important object already have names (e.g. broadcasters&listeners).

clayborg added a subscriber: clayborg.EditedJan 8 2020, 4:55 PM

I don't mess with the expression parser all that much, but do we still want to see the pointer value in the log output?

current:

CompleteTagDecl[2] on (ASTContext*)0x7ff31f01d240 Completing (TagDecl*)0x7ff31f01d568 named DeclName1

Should the new one be

CompleteTagDecl[2] on scratch ASTContext. Completing (TagDecl*)0x7ff31f01d568 named Foo

Or include the pointer value and the name:

CompleteTagDecl[2] on scratch (ASTContext*)0x7ff31f01d240. Completing (TagDecl*)0x7ff31f01d568 named DeclName1

Might be nice to still see the pointer value in case there are multiple ASTContexts with the same name?

@clayborg We can easily append the ptr value to the display name. All names should always be unique as long as there is one target, but in the off-chance that one isn't unique it might be useful.

Perhaps it makes sense to modify the dump() method to also display the new name?

lldb/source/Plugins/ExpressionParser/Clang/ClangExpressionParser.cpp
610

AST -> ASTContext?

lldb/source/Plugins/ExpressionParser/Clang/ClangModulesDeclVendor.cpp
164

AST -> ASTContext?

lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCDeclVendor.cpp
147

AST -> ASTContext?

Below you use "scratch ASTContext"

lldb/source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleObjCTypeEncodingParser.cpp
27

AST -> ASTContext?

lldb/unittests/Symbol/TestClangASTContext.cpp
29–30

AST -> ASTContext?

lldb/unittests/SymbolFile/DWARF/DWARFASTParserClangTests.cpp
42

dummy -> dummy ASTContext

lldb/unittests/TestingSupport/Symbol/ClangTestUtils.h
25–26

AST -> ASTContext?

shafik accepted this revision.Jan 9 2020, 10:48 AM
This revision is now accepted and ready to land.Jan 9 2020, 10:48 AM

@clayborg We can easily append the ptr value to the display name. All names should always be unique as long as there is one target, but in the off-chance that one isn't unique it might be useful.

I think the pointer values would be useful to have.

I don't know if this needs a unit test where we call the constructor and explicitly check the name is the one we passed in. Let me know if you think this would make sense.

I think we should.

This revision was automatically updated to reflect the committed changes.