Project Ortega BCM5719 LLVM https://git.raptorcs.com/git/bcm5719-llvm/atom?h=meklort-10.0.1 2020-01-02T10:54:45+00:00 2020-01-02T10:54:45+00:00 Raphael Isemann teemperor@gmail.com 2019-12-30T20:20:01+00:00 urn:sha1:fe8e25a48a2a0f8f508499ba950181dba3d600b0 LLDB frequently converts QualType to CompilerType. This is currently done like this: result = CompilerType(this, qual_type_var.getAsOpaquePtr()) There are a few shortcomings in this current approach: 1. CompilerType's constructor takes a void* pointer so it isn't type safe. 2. We can't add any sanity checks to the CompilerType constructor (e.g. that the type actually belongs to the passed ClangASTContext) without expanding the TypeSystem API. 3. The logic for converting QualType->CompilerType is spread out over all of LLDB so changing it is difficult (e.g., what if we want to just pass the type ptr and not the 1type_ptr | qual_flags1 to CompilerType). This patch adds a `ClangASTContext::GetType` function similar to the other GetTypeForDecl functions that does this conversion in a type safe way. It also adds a sanity check for Tag-based types that the type actually belongs to the current ClangASTContext (Types don't seem to know their ASTContext, so we have to workaround by looking at the decl for the underlying TagDecl. This doesn't cover all types we construct but it's better than no sanity check). 2019-12-23T08:56:54+00:00 Raphael Isemann teemperor@gmail.com 2019-12-23T08:05:07+00:00 urn:sha1:42ec584a8b4e604360b7a4d45a65c570d58b1bf9 The CompilerDeclContext constructor takes a void* pointer which means that all callers of this constructor need to first explicitly convert all pointers to clang::DeclContext*. This causes that we for example can't just pass a TranslationUnitDecl* to the constructor without first casting it to its parent class (as it inherits from both Decl and DeclContext so the void* pointer is actually a Decl*). This patch introduces a utility function in the ClangASTContext which gets rid of the requirement to cast all pointers to clang::DeclContext. Also moves all constructor calls to use this function instead which is NFC (beside the change in DWARFASTParserClangTests.cpp). 2019-12-21T21:51:35+00:00 Raphael Isemann teemperor@gmail.com 2019-12-21T21:40:52+00:00 urn:sha1:f9f49d3594bc7584cc5cb96125ca08f2ad97662c ClangASTContext::getASTContext() currently returns a ptr but we have an assert there since a while that the ASTContext is not a nullptr. This causes that we still have a lot of code that is doing nullptr checks on the result of getASTContext() which is all unreachable code. This patch changes the return value to a reference to make it clear this can't be a nullptr and deletes all the nullptr checks. 2019-12-17T15:10:34+00:00 Raphael Isemann teemperor@gmail.com 2019-12-17T15:00:51+00:00 urn:sha1:268f37df6e45c4b0603bd4d964483a0d84da44c1 2019-12-17T14:56:07+00:00 Raphael Isemann teemperor@gmail.com 2019-12-17T13:34:17+00:00 urn:sha1:b852b3c982d2e8ad3f13c626b3e3655e5b3c399e This function is just setting the layout for the given RecordDecl so the current name is not very descriptive. Also add some documentation for it. 2019-12-17T10:21:11+00:00 Raphael Isemann teemperor@gmail.com 2019-12-17T10:06:01+00:00 urn:sha1:d9ca412a8a75ab64af33a9e95d1319c4dd2004d2 These files only need the definition of ClangASTMetadata (which was previously in the ClangASTSourceCommon.h) or don't need the include at all. 2019-12-05T10:37:18+00:00 Pavel Labath pavel@labath.sk 2019-11-28T09:19:23+00:00 urn:sha1:57f8a998ceaf36e021878e8810bb57a00452c07d Summary: Lldb's "format-independent" debug info made use of the fact that DWARF (<=4) did not use the file index zero, and reused the support file index zero for storing the compile unit name. While this provided some convenience for DWARF<=4, it meant that the PDB plugin needed to artificially remap file indices in order to free up index 0. Furthermore, DWARF v5 make file index 0 legal, which meant that similar remapping would be needed in the dwarf plugin too. What this patch does instead is remove the requirement of having the compile unit name in the index 0. It is not that useful since the name can always be fetched from the CompileUnit object. Remapping code in the pdb plugin(s) has been removed or simplified. DWARF plugin has started inserting an empty FileSpec at index 0 to ensure the indices keep matching up (in case of DWARF<=4). For DWARF5, we insert the file 0 from the line table. I add a test to ensure we can correctly lookup line table entries referencing file 0, and in particular the case where the file 0 is also duplicated in another file entry, as this is how clang produces line tables in some circumstances (see pr44170). Though this is probably a bug in clang, this is not forbidden by DWARF, and lldb already has support for that in some (but not all) cases -- this adds a test for the code path which was not fixed in this patch. Reviewers: clayborg, JDevlieghere, jdoerfert Subscribers: aprantl, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70954 2019-11-18T18:00:26+00:00 Adrian Prantl aprantl@apple.com 2019-11-18T17:58:16+00:00 urn:sha1:d4f18f11d372bd02127424ae6a8f8a30f77a0426 Due to alginment and packing using separate members takes up the same amount of space, but makes it far less cumbersome to deal with it in constructors etc. 2019-11-15T19:52:13+00:00 Adrian Prantl aprantl@apple.com 2019-11-15T18:13:16+00:00 urn:sha1:7d71dd928d1dcc838dc4dbe5cf294f557609f271 Differential Revision: https://reviews.llvm.org/D70322 2019-11-12T17:38:37+00:00 Adrian Prantl aprantl@apple.com 2019-11-12T17:25:59+00:00 urn:sha1:3b73dcdc9656e156c4380454150b8986c5b9aad1 This is basically the same bug as in r260434. SymbolFileDWARF::FindTypes has exponential worst-case when digging through dependency DAG of .pcm files because each object file and .pcm file may depend on an already-visited .pcm file, which may again have dependencies. Fixed here by carrying a set of already visited SymbolFiles around. rdar://problem/56993424 Differential Revision: https://reviews.llvm.org/D70106