Fix an embarrasing use-after-free from a895a446bcde
[lldb/test] Simplify/generalize YAMLModuleTesterThe class only supports a single DWARF unit (needed for my new test), and itreimplements chunks of object and symbol file classes. We can just make
[lldb/test] Simplify/generalize YAMLModuleTesterThe class only supports a single DWARF unit (needed for my new test), and itreimplements chunks of object and symbol file classes. We can just make it usethe real thing, save some LOC and get the full feature set.Differential Revision: https://reviews.llvm.org/D90393
show more ...
[lldb/cmake] Fix linking of lldbSymbolHelpers for 9cb222e7I didn't find this locally because I have a /usr/include/gtest which issimilar enough to the bundled one to make things appear to work.
[cmake] Make gtest include directories a part of the library interfaceThis applies the same fix that D84748 did for macro definitions.Appropriate include path is now automatically set for all libr
[cmake] Make gtest include directories a part of the library interfaceThis applies the same fix that D84748 did for macro definitions.Appropriate include path is now automatically set for all librarieswhich link against gtest targets, which avoids the need to setinclude_directories in various parts of the project.Differential Revision: https://reviews.llvm.org/D86616
[cmake] Make gtest macro definitions a part the library interfaceThese definitions are needed by any file which uses gtest. Previously wewere adding them in the add_unittest function, but over tim
[cmake] Make gtest macro definitions a part the library interfaceThese definitions are needed by any file which uses gtest. Previously wewere adding them in the add_unittest function, but over time we'veaccumulated libraries (which don't go through add_unittest) building ongtest and this has resulted in proliferation of the definitions.Making this a part of the library interface enables them to be managedcentrally. This follows a patch for -Wno-suggest-override (D84554) whichtook a similar approach.Differential Revision: https://reviews.llvm.org/D84748
[lldb] Use modern CMake to avoid repetition (NFC)Use the target variants of include_directories and add_definitions toavoid repetition.
[DWARFYAML] Refactor emitDebugInfo() to make the length be inferred.This patch refactors `emitDebugInfo()` to make the length field beinferred from its content. Besides, the `Visitor` class is rem
[DWARFYAML] Refactor emitDebugInfo() to make the length be inferred.This patch refactors `emitDebugInfo()` to make the length field beinferred from its content. Besides, the `Visitor` class is removed inthis patch. The original `Visitor` class helps us determine anappropriate length and emit the .debug_info section. These twoprocesses can be merged into one process. Besides, the length fieldshould be inferred when it's missing rather than when it's zero.Reviewed By: jhenderson, labathDifferential Revision: https://reviews.llvm.org/D84008
[lldb] Fix YAMLModuleTester for the rename in 67b4afc4
Add a getter to retrieve the XcodeSDK from Module and unit-test it. (NFC)This API is used by swift-lldb.(Recommit with missing file git-added)
Revert "Add a getter to retrieve the XcodeSDK from Module and unit-test it. (NFC)"This reverts commit 345df863ce649860bea9040fe5c2f10780d29080.(Forgot to git-add the new file)
Add a getter to retrieve the XcodeSDK from Module and unit-test it. (NFC)This API is used by swift-lldb.
Preserve the owning module information from DWARF in the synthesized ASTTypes that came from a Clang module are nested in DW_TAG_module tagsin DWARF. This patch recreates the Clang module hierarch
Preserve the owning module information from DWARF in the synthesized ASTTypes that came from a Clang module are nested in DW_TAG_module tagsin DWARF. This patch recreates the Clang module hierarchy in LLDB and1;95;0csets the owning module information accordingly. My primary motivationis to facilitate looking up per-module APINotes for individualdeclarations, but this likely also has other applications.This reapplies the previously reverted commit, but without support forClassTemplateSpecializations, which I'm going to look into separately.rdar://problem/59634380Differential Revision: https://reviews.llvm.org/D75488
Revert "Preserve the owning module information from DWARF in the synthesized AST"This reverts commit 4354dfbdf5c8510a7ddff10ae67a28e16cf7cc79 while investigating bot fallout.
Preserve the owning module information from DWARF in the synthesized ASTTypes that came from a Clang module are nested in DW_TAG_module tagsin DWARF. This patch recreates the Clang module hierarchy in LLDB andsets the owning module information accordingly. My primary motivationis to facilitate looking up per-module APINotes for individualdeclarations, but this likely also has other applications.rdar://problem/59634380Differential Revision: https://reviews.llvm.org/D75488
[lldb/DWARF] Re-enable basic dwp supportSummary:This patch removes the bitrotted SymbolFileDWARF(Dwo)Dwp classes, andreplaces them with dwp support implemented directly insideSymbolFileDWARFDwo,
[lldb/DWARF] Re-enable basic dwp supportSummary:This patch removes the bitrotted SymbolFileDWARF(Dwo)Dwp classes, andreplaces them with dwp support implemented directly insideSymbolFileDWARFDwo, in a manner mirroring the implementation in llvm.This patch does:- add support for the .debug_cu_index section to our DWARFContext- adds a llvm::DWARFUnitIndex argument to the DWARFUnit constructors. This argument is used to look up the offsets of the debug_info and debug_abbrev contributions in the sections of the dwp file.- makes sure the creation of the DebugInfo object as well as the initial discovery of DWARFUnits is thread-safe, as we can now call this concurrently when doing parallel indexing.This patch does not:- use the DWARFUnitIndex to search for other kinds of contributions (debug_loc, debug_ranges, etc.). This means that units which reference these sections will not work correctly. These will be handled by follow-up patches, but even the present level of support is sufficient to enable basic functionality.- Make the llvm::DWARFContext thread-safe. Right now, it just avoids this problem by ensuring everything is initialized ahead of time. However, this is something we will run into more often as we try to use more of llvm, and so I plan to start looking into our options here.Reviewers: JDevlieghere, aprantl, clayborgSubscribers: mgorny, mgrang, lldb-commitsTags: #lldbDifferential Revision: https://reviews.llvm.org/D73783
[lldb/Unittest] Fix the modules build by including TypeSystemClang.hThis should fix the modules build on the GreenDragon bot.
Re-land "[lldb] [testsuite] generalize `DWARFASTParserClangTests` based on `DWARFExpressionTest`'s YAML"
Revert: [lldb] [testsuite] generalize `DWARFASTParserClangTests` based on `DWARFExpressionTest`'s YAMLIt is causing a failure on OSX, to be investigated more.Differential Revision: https://review
Revert: [lldb] [testsuite] generalize `DWARFASTParserClangTests` based on `DWARFExpressionTest`'s YAMLIt is causing a failure on OSX, to be investigated more.Differential Revision: https://reviews.llvm.org/D73279
[lldb] [testsuite] Fixup: generalize `DWARFASTParserClangTests` based on `DWARFExpressionTest`'s YAMLThe testcase did not compile now because of an upstream change in themeantime.For: https://re
[lldb] [testsuite] Fixup: generalize `DWARFASTParserClangTests` based on `DWARFExpressionTest`'s YAMLThe testcase did not compile now because of an upstream change in themeantime.For: https://reviews.llvm.org/D73279
[lldb] [testsuite] generalize `DWARFASTParserClangTests` based on `DWARFExpressionTest`'s YAMLYAMLModuleTester from DWARFExpressionTest can be reused for moretestcases.Differential Revision: htt
[lldb] [testsuite] generalize `DWARFASTParserClangTests` based on `DWARFExpressionTest`'s YAMLYAMLModuleTester from DWARFExpressionTest can be reused for moretestcases.Differential Revision: https://reviews.llvm.org/D73279
[lldb] Move clang-based files out of SymbolSummary:This change represents the move of ClangASTImporter, ClangASTMetadata,ClangExternalASTSourceCallbacks, ClangUtil, CxxModuleHandler, andTypeSyst
[lldb] Move clang-based files out of SymbolSummary:This change represents the move of ClangASTImporter, ClangASTMetadata,ClangExternalASTSourceCallbacks, ClangUtil, CxxModuleHandler, andTypeSystemClang from lldbSource to lldbPluginExpressionParserClang.hThis explicitly removes knowledge of clang internals from lldbSymbol,moving towards a more generic core implementation of lldb.Reviewers: JDevlieghere, davide, aprantl, teemperor, clayborg, labath, jingham, shafikSubscribers: emaste, mgorny, arphaman, jfb, usaxena95, lldb-commitsTags: #lldbDifferential Revision: https://reviews.llvm.org/D73661
[lldb][NFC] Rename ClangASTContext to TypeSystemClangSummary:This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do(implement the Type
[lldb][NFC] Rename ClangASTContext to TypeSystemClangSummary:This commit renames ClangASTContext to TypeSystemClang to better reflect what this class is actually supposed to do(implement the TypeSystem interface for Clang). It also gets rid of the very confusing situation that we have both a`clang::ASTContext` and a `ClangASTContext` in clang (which sometimes causes Clang people to think I'm fiddlingwith Clang's ASTContext when I'm actually just doing LLDB work).I also have plans to potentially have multiple clang::ASTContext instances associated with one ClangASTContext sothe ASTContext naming will then become even more confusing to people.Reviewers: #lldb, aprantl, shafik, clayborg, labath, JDevlieghere, davide, espindola, jdoerfert, xiaobaiReviewed By: clayborg, labath, xiaobaiSubscribers: wuzish, emaste, nemanjai, mgorny, kbarton, MaskRay, arphaman, jfb, usaxena95, jingham, xiaobai, abidh, JDevlieghere, lldb-commitsTags: #lldbDifferential Revision: https://reviews.llvm.org/D72684
[lldb] Add a display name to ClangASTContext instancesSummary:I often struggle to understand what exactly LLDB is doing by looking at our expression evaluation logging as our messages look like th
[lldb] Add a display name to ClangASTContext instancesSummary: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 tofigure out what this ASTContext is without having deeper understanding about all the different ASTContext instances in LLDB (e.g., valid SourceLocationfrom 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 thisour 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";```Reviewers: shafik, labath, JDevlieghere, mibReviewed By: shafikSubscribers: clayborg, lldb-commitsTags: #lldbDifferential Revision: https://reviews.llvm.org/D72391
[lldb][NFC] Return a reference from ClangASTContext::getASTContext and remove dead nullptr checksClangASTContext::getASTContext() currently returns a ptr but we have an assert there since awhile t
[lldb][NFC] Return a reference from ClangASTContext::getASTContext and remove dead nullptr checksClangASTContext::getASTContext() currently returns a ptr but we have an assert there since awhile that the ASTContext is not a nullptr. This causes that we still have a lot of codethat 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 nullptrand deletes all the nullptr checks.
[lldb][NFC] Remove all ASTContext getter wrappers from ClangASTContextTheir naming is misleading as they only return theClangASTContext-owned variables. For ClangASTContext instances constructedf
[lldb][NFC] Remove all ASTContext getter wrappers from ClangASTContextTheir naming is misleading as they only return theClangASTContext-owned variables. For ClangASTContext instances constructedfor a given clang::ASTContext they silently generated duplicated instances(e.g., a second IdentifierTable) that were essentially unusable.This removes all these getters as they are anyway not very useful in comparisonto just calling the clang::ASTContext getters. The initializationcode has been moved to the CreateASTContext initialization method so that allcode for making our own clang::ASTContext is in one place.
12