[Lldb-commits] [PATCH] D71409: [lldb][NFC] Make metadata tracking type safe

Raphael Isemann via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Thu Dec 12 04:24:58 PST 2019

teemperor created this revision.
teemperor added reviewers: labath, shafik, aprantl.
Herald added subscribers: lldb-commits, JDevlieghere.
Herald added a project: LLDB.
teemperor added a comment.
teemperor edited the summary of this revision.

(I'm aware that a lot of the touched code here could be improved, but I would prefer that I at least can trust my compiler before I refactor the remaining Metadata stuff...)

LLDB associates additional information with Types and Declarations which it calls ClangASTMetadata.
ClangASTMetadata is stored by the ClangASTSourceCommon which is implemented by having a large map of
`void *` keys to associated `ClangASTMetadata` values. To make this whole mechanism even unsafer
we also decided to use `clang::Decl *` as one of pointers we throw in there (beside `clang::Type *`).

The Decl class hierarchy uses multiple inheritance which means that not all pointers have the
same address when they are implicitly converted to pointers of their parent classes. For example
`clang::Decl *` and `clang::DeclContext *` won't end up being the same address when they
are implicitly converted from one of the many Decl-subclasses that inherit from both.

As we use the addresses as the keys in our Metadata map, this means that any implicit type
conversions to parent classes (or anything else that changes the addresses) will break our metadata tracking
in obscure ways.

Just to illustrate how broken this whole mechanism currently is:

  // m_ast is our ClangASTContext. Let's double check that from GetTranslationUnitDecl
  // in ClangASTContext and ASTContext return the same thing (one method just calls the other).
  assert(m_ast->GetTranslationUnitDecl() == m_ast->getASTContext()->getTranslationUnitDecl());
  // Ok, both methods have the same TU*. Let's store metadata with the result of one method call.
  m_ast->SetMetadataAsUserID(m_ast->GetTranslationUnitDecl(), 1234U);
  // Retrieve the same Metadata for the TU by using the TU* from the other method... which fails?
  EXPECT_EQ(m_ast->GetMetadata(m_ast->getASTContext()->getTranslationUnitDecl())->GetUserID(), 1234U);
  // Turns out that getTranslationUnitDecl one time returns a TranslationUnitDecl* but the other time
  // we return one of the parent classes of TranslationUnitDecl (DeclContext).

This patch splits up the `void *` API into two where one does the `clang::Type *` tracking and one the `clang::Decl *` mapping.
Type and Decl are disjoint class hierarchies so there is no implicit conversion possible that could influence
the address values.

I had to change the storing of `clang::QualType` opaque pointers to their `clang::Type *` equivalents as
opaque pointers are already `void *` pointers to begin with. We don't seem to ever set any qualifier in any of these
QualTypes to this conversion should be NFC.




-------------- next part --------------
A non-text attachment was scrubbed...
Name: D71409.233565.patch
Type: text/x-patch
Size: 8725 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/lldb-commits/attachments/20191212/2a0e483b/attachment.bin>

More information about the lldb-commits mailing list