summaryrefslogtreecommitdiffstats
path: root/lldb/source/Symbol
Commit message (Collapse)AuthorAgeFilesLines
...
* [LanguageRuntime] Move ObjCLanguageRuntime into a pluginAlex Langford2019-07-152-1/+2
| | | | | | | | | | | | | | Summary: Following up to my CPPLanguageRuntime change, I'm moving ObjCLanguageRuntime into a plugin as well. Reviewers: JDevlieghere, compnerd, jingham, clayborg Subscribers: mgorny, arphaman, lldb-commits Differential Revision: https://reviews.llvm.org/D64763 llvm-svn: 366148
* [lldb] Added assert to VerifyDeclRaphael Isemann2019-07-051-1/+4
| | | | | | | We could VerifyDecl sometimes with a nullptr. It would be nice if we could get an actual assert here instead of triggering UB. llvm-svn: 365247
* Add assert for 'bad' code path in GetUniqueNamespaceDeclarationRaphael Isemann2019-07-041-1/+2
| | | | | | | | | | | | | | | | | Summary: If we call this function with a non-namespace as a second argument (and a nullptr name), we currently only get a nullptr as a return when we hit the "Bad!!!" code path. This patch just adds an assert as this seems to be a programming error in the calling code. Reviewers: shafik Subscribers: abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D57880 llvm-svn: 365157
* [Symbol] Add DeclVendor::FindTypesAlex Langford2019-07-022-0/+30
| | | | | | | | | | | | | Summary: Following up on the plan I outlined in D63622, we can remove the dependence on clang in all the places where we only want to find the types from the DeclVendor. This means that currently DeclVendor depends on clang, but centralizing the dependency makes it easier to refactor cleanly. Differential Revision: https://reviews.llvm.org/D63853 llvm-svn: 364962
* [Core] Generalize ValueObject::IsRuntimeSupportValueAlex Langford2019-07-011-2/+6
| | | | | | | | | | | | | | | Summary: Instead of falling back to ObjCLanguageRuntime, we should be falling back to every loaded language runtime. This makes ValueObject more language agnostic. Reviewers: labath, compnerd, JDevlieghere, davide Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D63240 llvm-svn: 364845
* Fix lookup of symbols at the same address with no size vs. sizeJan Kratochvil2019-07-011-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This fixes a failing testcase on Fedora 30 x86_64 (regression Fedora 29->30): PASS: ./bin/lldb ./lldb-test-build.noindex/functionalities/unwind/noreturn/TestNoreturnUnwind.test_dwarf/a.out -o 'settings set symbols.enable-external-lookup false' -o r -o bt -o quit * frame #0: 0x00007ffff7aa6e75 libc.so.6`__GI_raise + 325 frame #1: 0x00007ffff7a91895 libc.so.6`__GI_abort + 295 frame #2: 0x0000000000401140 a.out`func_c at main.c:12:2 frame #3: 0x000000000040113a a.out`func_b at main.c:18:2 frame #4: 0x0000000000401134 a.out`func_a at main.c:26:2 frame #5: 0x000000000040112e a.out`main(argc=<unavailable>, argv=<unavailable>) at main.c:32:2 frame #6: 0x00007ffff7a92f33 libc.so.6`__libc_start_main + 243 frame #7: 0x000000000040106e a.out`_start + 46 vs. FAIL - unrecognized abort() function: ./bin/lldb ./lldb-test-build.noindex/functionalities/unwind/noreturn/TestNoreturnUnwind.test_dwarf/a.out -o 'settings set symbols.enable-external-lookup false' -o r -o bt -o quit * frame #0: 0x00007ffff7aa6e75 libc.so.6`.annobin_raise.c + 325 frame #1: 0x00007ffff7a91895 libc.so.6`.annobin_loadmsgcat.c_end.unlikely + 295 frame #2: 0x0000000000401140 a.out`func_c at main.c:12:2 frame #3: 0x000000000040113a a.out`func_b at main.c:18:2 frame #4: 0x0000000000401134 a.out`func_a at main.c:26:2 frame #5: 0x000000000040112e a.out`main(argc=<unavailable>, argv=<unavailable>) at main.c:32:2 frame #6: 0x00007ffff7a92f33 libc.so.6`.annobin_libc_start.c + 243 frame #7: 0x000000000040106e a.out`.annobin_init.c.hot + 46 The extra ELF symbols are there due to Annobin (I did not investigate why this problem happened specifically since F-30 and not since F-28). It is due to: Symbol table '.dynsym' contains 2361 entries: Valu e Size Type Bind Vis Name 0000000000022769 5 FUNC LOCAL DEFAULT _nl_load_domain.cold 000000000002276e 0 NOTYPE LOCAL HIDDEN .annobin_abort.c.unlikely ... 000000000002276e 0 NOTYPE LOCAL HIDDEN .annobin_loadmsgcat.c_end.unlikely ... 000000000002276e 0 NOTYPE LOCAL HIDDEN .annobin_textdomain.c_end.unlikely 000000000002276e 548 FUNC GLOBAL DEFAULT abort 000000000002276e 548 FUNC GLOBAL DEFAULT abort@@GLIBC_2.2.5 000000000002276e 548 FUNC LOCAL DEFAULT __GI_abort 0000000000022992 0 NOTYPE LOCAL HIDDEN .annobin_abort.c_end.unlikely Differential Revision: https://reviews.llvm.org/D63540 llvm-svn: 364773
* Use const auto *Fangrui Song2019-06-291-2/+2
| | | | llvm-svn: 364702
* Get the expression parser to handle missing weak symbols.Jim Ingham2019-06-281-5/+10
| | | | | | | | | | MachO only for this patch. Differential Revision: https://reviews.llvm.org/D63914 <rdar://problem/51463642> llvm-svn: 364686
* Don't link against the DebugSymbols private framework; try to dlopenJason Molenda2019-06-241-14/+18
| | | | | | | | | | | | | | | | | | | | | | | + dlsym the two functions we need from there at runtime. I'm not maintaining a negative cache if DebugSymbols is absent, so we'll try to dlopen() it on every call to LocateMacOSXFilesUsingDebugSymbols but this file is only built on mac and iOS type systems, so there's a slight perf impact running lldb on an iOS type system. I store the function pointer results in two global variables without any locking; two threads calling into LocateMacOSXFilesUsingDebugSymbols for the first time will both try to set these fptrs, but they'll be setting them to the same value, so I'm not too worried. I didn't see where in the cmake build configurations we link against DebugSymbols, but I removed the dependency from the xcode project file. <rdar://problem/49458356> llvm-svn: 364243
* Remove stale comment and disabled code (NFC)Jonas Devlieghere2019-06-141-19/+0
| | | | llvm-svn: 363438
* [C++20] add Basic consteval specifierGauthier Harnisch2019-06-141-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: this revision adds Lexing, Parsing and Basic Semantic for the consteval specifier as specified by http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2018/p1073r3.html with this patch, the consteval specifier is treated as constexpr but can only be applied to function declaration. Changes: - add the consteval keyword. - add parsing of consteval specifier for normal declarations and lambdas expressions. - add the whether a declaration is constexpr is now represented by and enum everywhere except for variable because they can't be consteval. - adapt diagnostic about constexpr to print constexpr or consteval depending on the case. - add tests for basic semantic. Reviewers: rsmith, martong, shafik Reviewed By: rsmith Subscribers: eraman, efriedma, rnkovacs, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D61790 llvm-svn: 363362
* Make UniqueCStringMap work with non-default-constructible types and other ↵Pavel Labath2019-06-141-41/+30
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | improvements/cleanups Summary: The motivation for this was me wanting to make the validity of dwarf DIERefs explicit (via llvm::Optional<DIERef>). This meant that the class would no longer have a default constructor. As the DIERef was being stored in a UniqueCStringMap, this meant that this container (like all standard containers) needed to work with non-default-constructible types too. This part is achieved by removing the default constructors for the map entry types, and providing appropriate comparison overloads so that we can search for map entries without constructing a dummy entry. While doing that, I took the opportunity to modernize the code, and add some tests. Functions that were completely unused are deleted. This required also some changes in the Symtab code, as it was default constructing map entries, which was not impossible even though its value type was default-constructible. Technically, these changes could be avoided with some SFINAE on the entry type, but I felt that the code is cleaner this way anyway. Reviewers: JDevlieghere, sgraenitz Subscribers: mgorny, aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D63268 llvm-svn: 363357
* Recognise debug_types.dwo as a debug info sectionPavel Labath2019-06-121-0/+1
| | | | | | This is a preparatory patch to allow reading type units from dwo files. llvm-svn: 363146
* [Target] Remove Process::GetObjCLanguageRuntimeAlex Langford2019-06-101-2/+2
| | | | | | | | | | | Summary: In an effort to make Process more language agnostic, I removed GetCPPLanguageRuntime from Process. I'm following up now with an equivalent change for ObjC. Differential Revision: https://reviews.llvm.org/D63052 llvm-svn: 362981
* [ABI] Fix SystemV ABI to handle nested aggregate type returned in registerAlex Langford2019-06-041-0/+8
| | | | | | | | | | Add a function to flatten the nested aggregate type Differential Revision: https://reviews.llvm.org/D62702 Patch by Wanyi Ye <kusmour@gmail.com> llvm-svn: 362543
* Make CompileUnit::GetSupportFiles return a const listPavel Labath2019-05-301-2/+2
| | | | | | | | | | | | There's no reason for anyone to modify a list from outside of a symbol file (as that would break a lot of invariants that symbol files depend on). Make the function return a const FileSpecList and fix up a couple of places that were needlessly binding non-const references to the result of this function. llvm-svn: 362069
* [DWARFExpression] Remove ctor that takes just a compile unit.Jonas Devlieghere2019-05-281-1/+1
| | | | | | | | | | | | | | | | Like many of our DWARF classes, the DWARFExpression can be initialized in several ways. One such way was through a constructor that takes just the compile unit. This constructor is used to initialize both empty DWARFExpressions, and DWARFExpression that will be populated later. To make the distinction more clear, I changed the constructor to a default constructor and updated its call sites. Where the DWARFExpression was being populated later, I replaced that with a call to the copy assignment constructor. Differential revision: https://reviews.llvm.org/D62425 llvm-svn: 361849
* FuncUnwinders: prefer debug_frame over eh_framePavel Labath2019-05-271-4/+4
| | | | | | | | | | | | | | | The two sections usually contain the same information, and we rarely have both kinds of entries for a single function. However, in theory the debug_frame plan can be more complete, whereas eh_frame is only required to be correct at places where exceptions can be thrown. Reviewers: jasonmolenda, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D62374 llvm-svn: 361758
* [FuncUnwinders] Use "symbol file" unwind plans for unwindingPavel Labath2019-05-241-1/+6
| | | | | | | | | | | | | | | | | Summary: Previous patch (r360409) introduced the "symbol file unwind plan" concept, but that plan wasn't used for unwinding yet. With this patch, we start to consider the new plan as a possible strategy for both synchronous and asynchronous unwinding. I also add a test that asserts that unwinding via breakpad STACK CFI info works end-to-end. Reviewers: jasonmolenda, clayborg Subscribers: lldb-commits, amccarth, markmentovai Differential Revision: https://reviews.llvm.org/D61853 llvm-svn: 361618
* Fix integer literals which are cast to boolJonas Devlieghere2019-05-245-7/+7
| | | | | | | | | This change replaces built-in types that are implicitly converted to booleans. Differential revision: https://reviews.llvm.org/D62284 llvm-svn: 361580
* [lldb] NFC modernize codebase with modernize-use-nullptrKonrad Kleine2019-05-238-21/+22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]] This commit is the result of modernizing the LLDB codebase by using `nullptr` instread of `0` or `NULL`. See https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html for more information. This is the command I ran and I to fix and format the code base: ``` run-clang-tidy.py \ -header-filter='.*' \ -checks='-*,modernize-use-nullptr' \ -fix ~/dev/llvm-project/lldb/.* \ -format \ -style LLVM \ -p ~/llvm-builds/debug-ninja-gcc ``` NOTE: There were also changes to `llvm/utils/unittest` but I did not include them because I felt that maybe this library shall be updated in isolation somehow. NOTE: I know this is a rather large commit but it is a nobrainer in most parts. Reviewers: martong, espindola, shafik, #lldb, JDevlieghere Reviewed By: JDevlieghere Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits Tags: #lldb, #llvm Differential Revision: https://reviews.llvm.org/D61847 llvm-svn: 361484
* Add AST loggingGabor Marton2019-05-221-0/+22
| | | | | | | | | | | | | | | | Summary: Log the AST of the TU associated with LLDB's `expr` command, once a declaration is completed Reviewers: shafik Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D62061 llvm-svn: 361362
* [Symbol] Remove dead codeAlex Langford2019-05-221-55/+0
| | | | llvm-svn: 361337
* [CMake] Correct some dependenciesAlex Langford2019-05-211-1/+0
| | | | | | Symbol doesn't depend on CPlusPlusLanguage, but Expressiond does. llvm-svn: 361216
* Delete unnecessary copy ctors/copy assignment operatorsFangrui Song2019-05-152-29/+0
| | | | | | It's the simplest and gives the cleanest semantics. llvm-svn: 360762
* [ASTImporter] Use llvm::Expected and Error in the importer APIGabor Marton2019-05-153-39/+80
| | | | | | | | | | | | | | | | | | | | | | Summary: This is the final phase of the refactoring towards using llvm::Expected and llvm::Error in the ASTImporter API. This involves the following: - remove old Import functions which returned with a pointer, - use the Import_New functions (which return with Err or Expected) everywhere and handle their return value - rename Import_New functions to Import This affects both Clang and LLDB. Reviewers: shafik, teemperor, aprantl, a_sidorin, balazske, a.sidorin Subscribers: rnkovacs, dkrupp, Szelethus, gamesh411, cfe-commits, lldb-commits Tags: #clang, #lldb Differential Revision: https://reviews.llvm.org/D61438 llvm-svn: 360760
* Fix file names in file headers. NFCFangrui Song2019-05-132-2/+2
| | | | llvm-svn: 360554
* FuncUnwinders: Add a new "SymbolFile" unwind planPavel Labath2019-05-103-1/+45
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: some unwind formats are specific to a single symbol file and so it does not make sense for their parsing code live in the general Symbol library (as is the case with eh_frame for instance). This is the case for the unwind information in breakpad files, but the same will probably be true for PDB unwind info (once we are able to parse that). This patch adds the ability to fetch an unwind plan provided by a symbol file plugin, as discussed in the RFC at <http://lists.llvm.org/pipermail/lldb-dev/2019-February/014703.html>. I've kept the set of changes to a minimum, as there is no way to test them until we have a symbol file which implements this API -- that is comming in a follow-up patch, which will also implicitly test this change. The interesting part here is the introduction of the "RegisterInfoResolver" interface. The reason for this is that breakpad needs to be able to resolve register names (which are present as strings in the file) into register enums so that it can construct the unwind plan. This is normally done via the RegisterContext class, handing this over to the SymbolFile plugin would mean that it has full access to the debugged process, which is not something we want it to have. So instead, I create a facade, which only provides the ability to query register names, and hide the RegisterContext behind the facade. Also note that this only adds the ability to dump the unwind plan created by the symbol file plugin -- the plan is not used for unwinding yet -- this will be added in a third patch, which will add additional tests which makes sure the unwinding works as a whole. Reviewers: jasonmolenda, clayborg Subscribers: markmentovai, amccarth, lldb-commits Differential Revision: https://reviews.llvm.org/D61732 llvm-svn: 360409
* Fix up lldb after clang r360311.Richard Smith2019-05-091-2/+6
| | | | | | | | Patch by Tyker! Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360312
* PostfixExpression: Use signed integers in IntegerNodePavel Labath2019-05-071-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is necessary to support parsing expressions like ".cfa -16 + ^", as that format is used in breakpad STACK CFI expressions. Since the PDB expressions use the same parser, this change will affect them too, but I don't believe that should be a problem in practice. If PDBs do contain the negative values, it's very likely that they are intended to be parsed the same way, and if they don't, then it doesn't matter. In case that we do ever need to handle this differently, we can always make the parser behavior customizable, or just use a different parser. To make sure that the integer size is big enough for everyone, I switch from using a (unsigned) 32-bit integer to a 64-bit (signed) one. Reviewers: amccarth, clayborg, aleksandr.urakov Subscribers: markmentovai, lldb-commits Differential Revision: https://reviews.llvm.org/D61311 llvm-svn: 360166
* [lldb] Add MacroQualified switch cases for r360109Krasimir Georgiev2019-05-071-0/+6
| | | | | | | | | | | | | | | | | | Summary: r360109 added a new enum case, causing lldb build to fail with several errors like: lldb/source/Symbol/ClangASTContext.cpp:4342:11: error: enumeration value 'MacroQualified' not handled in switch [-Werror,-Wswitch] switch (qual_type->getTypeClass()) { ^ This adds the missing switch cases. I'm not an lldb maintainer and just used my best judgement that it's probably expected that we break in these cases. Feel free to ping / revert / fix this change if this behavior is not appropriate. Reviewers: gribozavr Reviewed By: gribozavr Differential Revision: https://reviews.llvm.org/D61640 llvm-svn: 360146
* Include inlined functions when figuring out a contiguous address rangeGreg Clayton2019-05-063-22/+64
| | | | | | | | | | | | | | | | | | | | | | | Checking this in for Antonio Afonso: This diff changes the function LineEntry::GetSameLineContiguousAddressRange so that it also includes function calls that were inlined at the same line of code. My motivation is to decrease the step over time of lines that heavly rely on inlined functions. I have multiple examples in the code base I work that makes a step over stop 20 or mote times internally. This can easly had up to step overs that take >500ms which I was able to lower to 25ms with this new strategy. The reason the current code is not extending the address range beyond an inlined function is because when we resolve the symbol at the next address of the line entry we will get the entry line corresponding to where the original code for the inline function lives, making us barely extend the range. This then will end up on a step over having to stop multiple times everytime there's an inlined function. To check if the range is an inlined function at that line I also get the block associated with the next address and check if there is a parent block with a call site at the line we're trying to extend. To check this I created a new function in Block called GetContainingInlinedBlockWithCallSite that does exactly that. I also added a new function to Declaration for convinence of checking file/line named CompareFileAndLine. To avoid potential issues when extending an address range I added an Extend function that extends the range by the AddressRange given as an argument. This function returns true to indicate sucess when the rage was agumented, false otherwise (e.g.: the ranges are not connected). The reason I do is to make sure that we're not just blindly extending complete_line_range by whatever GetByteSize() we got. If for some reason the ranges are not connected or overlap, or even 0, this could be an issue. I also added a unit tests for this change and include the instructions on the test itself on how to generate the yaml file I use for testing. Differential Revision: https://reviews.llvm.org/D61292 llvm-svn: 360071
* Revert r359949 "[clang] adding explicit(bool) from c++2a"Hans Wennborg2019-05-061-6/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This caused Clang to start erroring on the following: struct S {   template <typename = int> explicit S(); }; struct T : S {}; struct U : T {   U(); }; U::U() {} $ clang -c /tmp/x.cc /tmp/x.cc:10:4: error: call to implicitly-deleted default constructor of 'T' U::U() {}    ^ /tmp/x.cc:5:12: note: default constructor of 'T' is implicitly deleted because base class 'S' has no default constructor struct T : S {};            ^ 1 error generated. See discussion on the cfe-commits email thread. This also reverts the follow-ups r359966 and r359968. > this patch adds support for the explicit bool specifier. > > Changes: > - The parsing for the explicit(bool) specifier was added in ParseDecl.cpp. > - The storage of the explicit specifier was changed. the explicit specifier was stored as a boolean value in the FunctionDeclBitfields and in the DeclSpec class. now it is stored as a PointerIntPair<Expr*, 2> with a flag and a potential expression in CXXConstructorDecl, CXXDeductionGuideDecl, CXXConversionDecl and in the DeclSpec class. > - Following the AST change, Serialization, ASTMatchers, ASTComparator and ASTPrinter were adapted. > - Template instantiation was adapted to instantiate the potential expressions of the explicit(bool) specifier When instantiating their associated declaration. > - The Add*Candidate functions were adapted, they now take a Boolean indicating if the context allowing explicit constructor or conversion function and this boolean is used to remove invalid overloads that required template instantiation to be detected. > - Test for Semantic and Serialization were added. > > This patch is not yet complete. I still need to check that interaction with CTAD and deduction guides is correct. and add more tests for AST operations. But I wanted first feedback. > Perhaps this patch should be spited in smaller patches, but making each patch testable as a standalone may be tricky. > > Patch by Tyker > > Differential Revision: https://reviews.llvm.org/D60934 llvm-svn: 360024
* [lldb] Fix buildbot failure due to clang AST change.Nicolas Lesser2019-05-041-2/+6
| | | | | | | In r359949 several AST node constructors were modified without the corresponding change in lldb, which caused build failures. llvm-svn: 359966
* C.128 override, virtual keyword handlingRaphael Isemann2019-05-032-7/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: According to [C128] "Virtual functions should specify exactly one of `virtual`, `override`, or `final`", I've added override where a virtual function is overriden but the explicit `override` keyword was missing. Whenever both `virtual` and `override` were specified, I removed `virtual`. As C.128 puts it: > [...] writing more than one of these three is both redundant and > a potential source of errors. I anticipate a discussion about whether or not to add `override` to destructors but I went for it because of an example in [ISOCPP1000]. Let me repeat the comment for you here: Consider this code: ``` struct Base { virtual ~Base(){} }; struct SubClass : Base { ~SubClass() { std::cout << "It works!\n"; } }; int main() { std::unique_ptr<Base> ptr = std::make_unique<SubClass>(); } ``` If for some odd reason somebody removes the `virtual` keyword from the `Base` struct, the code will no longer print `It works!`. So adding `override` to destructors actively protects us from accidentally breaking our code at runtime. [C128]: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c128-virtual-functions-should-specify-exactly-one-of-virtual-override-or-final [ISOCPP1000]: https://github.com/isocpp/CppCoreGuidelines/issues/1000#issuecomment-476951555 Reviewers: teemperor, JDevlieghere, davide, shafik Reviewed By: teemperor Subscribers: kwk, arphaman, kadircet, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D61440 llvm-svn: 359868
* Hide runtime support values such as clang's __vla_expr from frame variableAdrian Prantl2019-05-021-1/+3
| | | | | | | | | | | | by respecting the "artificial" attribute on variables. Function arguments that are artificial and useful to end-users are being whitelisted by the language runtime. <rdar://problem/45322477> Differential Revision: https://reviews.llvm.org/D61451 llvm-svn: 359841
* Add std::stack and std::queue support to CxxModuleHandlerRaphael Isemann2019-05-021-0/+2
| | | | | | | | | | | | | | Reviewers: aprantl, shafik Reviewed By: aprantl, shafik Subscribers: lldb-commits Tags: #c_modules_in_lldb, #lldb Differential Revision: https://reviews.llvm.org/D61305 llvm-svn: 359779
* Rename Minion to ASTImporterDelegateRaphael Isemann2019-05-021-45/+52
| | | | | | | | | | | | | | | | | | Summary: I think there universal agreement that Minion isn't the best name for this class. This patch renames the class to ASTImporterDelegate to better reflect it's goal of monitoring and extending the ASTImporter. Reviewers: aprantl, shafik, martong, a.sidorin, davide Reviewed By: aprantl, shafik, davide Subscribers: rnkovacs, davide, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D61299 llvm-svn: 359777
* Sort Symbol/CMakeLists.txtJonas Devlieghere2019-04-301-5/+5
| | | | | | This makes resolving merge conflicts downstream a tad easier. llvm-svn: 359577
* PostfixExpression: Introduce InitialValueNodePavel Labath2019-04-301-2/+27
| | | | | | | | | | | | | | | | | | | | | | | Summary: This node represents can be used to refer to the initial value, which is sometimes pushed onto the DWARF stack as the "input" to the DWARF expression. The typical use case (and the reason why I'm introducing it) is that the "Canonical Frame Address" is passed this way to the DWARF expressions computing the values of registers during frame unwind. The nodes are converted into dwarf by keeping track of DWARF stack depth an any given point, and then copying the initial value from the bottom of the stack via the DW_OP_pick opcode. This could be made more efficient for simple expressions, but here I chose to start with the most general implementation possible. Reviewers: amccarth, clayborg, aleksandr.urakov Subscribers: aprantl, jasonmolenda, lldb-commits, markmentovai Differential Revision: https://reviews.llvm.org/D61183 llvm-svn: 359560
* Sort containers alphabetically in CxxModuleHandler [NFC]Raphael Isemann2019-04-301-3/+3
| | | | llvm-svn: 359546
* Instantiate 'std' templates explicitly in the expression evaluatorRaphael Isemann2019-04-304-0/+317
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch is a follow-up for D58125. It implements the manual instantiation and merging of 'std' templates like `std::vector` and `std::shared_ptr` with information from the debug info AST. This (finally) allows using these classes in the expression evaluator like every other class (i.e. things like `vec.size()` and shared_ptr debugging now works, yay!). The main logic is the `CxxModuleHandler` which intercept the ASTImporter import process and replaces any `std` decls by decls from the C++ module. The decls from the C++ module are "imported" by just deserializing them directly in the expression evaluation context. This is mostly because we don't want to rely on the ASTImporter to correctly import these declarations, but in the future we should also move to the ASTImporter for that. This patch doesn't contain the automatic desugaring for result variables. This means that if you call for example `size` of `std::vector` you maybe get some very verbose typedef'd type as the variable type, e.g. `std::vector<int, std::allocator<int>>::value_type`. This is not only unreadable, it also means that our ASTImporter has to import all these types and associated decls into the persisent variable context. This currently usually leads to some assertion getting triggered in Clang when the ASTImporter either makes a mistake during importing or our debug info AST is inconsitent. The current workaround I use in the tests is to just cast the result to it's actual type (e.g. `size_t` or `int`) to prevent the ASTImporter from having to handle all these complicated decls. The automatic desugaring will be a future patch because I'm not happy yet with the current code for that and because I anticipate that this will be a controversial patch. Reviewers: aprantl, shafik, jingham, martong, serge-sans-paille Reviewed By: martong Subscribers: balazske, rnkovacs, mgorny, mgrang, abidh, jdoerfert, lldb-commits Tags: #c_modules_in_lldb, #lldb Differential Revision: https://reviews.llvm.org/D59537 llvm-svn: 359538
* PostfixExpression: move DWARF generator out of NativePDB internalsPavel Labath2019-04-261-0/+120
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: The new dwarf generator is pretty much a verbatim copy of the one in PDB. In order to write a pdb-independent test for it, I needed to write a dummy "symbol resolver", which (together with the fact that I'll need one more for breakpad-specific resolution logic) prompted me to create a more simple interface for algorithms which replace or "resolve" SymbolNodes. The resolving algorithms in NativePDB have been updated to make use of that too. I have removed a couple of NativePDB tests which weren't testing anything pdb-specific and where the tested functionality was covered by the new format-agnostic tests I have added. Reviewers: amccarth, clayborg, aleksandr.urakov Subscribers: aprantl, markmentovai, lldb-commits, jasonmolenda, JDevlieghere Differential Revision: https://reviews.llvm.org/D61056 llvm-svn: 359288
* PostfixExpression: move parser out of NativePDB internalsPavel Labath2019-04-242-0/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The postfix expressions in PDB and breakpad symbol files are similar enough that they can be parsed by the same parser. This patch generalizes the parser in the NativePDB plugin and moves it into the PostfixExpression file created in the previous commit (r358976). The generalization consists of treating any unrecognised token as a "symbol" node (previously these would only be created for tokens starting with "$", and other token would abort the parse). This is needed because breakpad symbols can also contain ".cfa" tokens, which refer to the frame's CFA. The cosmetic changes include: - using a factory function instead of a class for creating nodes (this is more generic as it allows the same BumpPtrAllocator to be used for other things too) - using dedicated function for parsing operator tokens instead of a DenseMap (more efficient as we don't need to create the DenseMap every time). Reviewers: amccarth, clayborg, JDevlieghere, aleksandr.urakov Subscribers: jasonmolenda, lldb-commits, markmentovai, mgorny Differential Revision: https://reviews.llvm.org/D61003 llvm-svn: 359073
* FuncUnwinders: remove "current_offset" from function argumentsPavel Labath2019-04-232-68/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This argument was added back in 2010 (r118882) to support the ability to unwind from functions whose eh_frame entry does not cover the entire range of the function. However, due to the caching happening in FuncUnwinders, this solution is very fragile. FuncUnwinders will cache the plan it got from eh_frame regardless of the value of the current_offset, so our ability to unwind from a given function depended what was the value of "current_offset" the first time that this function was called. Furthermore, since the "image show-unwind" command did not know what's the right offset to pass, this created an unfortunate situation where "image show-unwind" would show no valid plans for a function, even though they were available and being used. In this patch I implement the feature slightly differently. Instead of giving just a base address to the eh_frame unwinder, I give it the entire range we are interested in. Then, I change the unwinder to return the first plan that covers (even partially) that range. This way even a partial plan will be returned, regardless of the address in the function where we are stopped at. This solution is still not 100% correct, as it will not handle a function which is covered by two independent fde entries. However, I don't expect anybody will write this kind of functions, and this wasn't handled by the previous implementation either. If this is ever needed in the future. The eh_frame unwinder can be extended to return "composite" unwind plans created by merging sevelar fde entries. I also create a test which triggers this scenario. As doing this is virtually impossible without hand-written assembly, the test only works on x86 linux. Reviewers: jasonmolenda, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D60829 llvm-svn: 358964
* UnwindPlan: pretty-print dwarf expressionsPavel Labath2019-04-231-4/+35
| | | | | | | | | | | | | | | | Summary: Previously we were printing the dwarf expressions in unwind rules simply as "dwarf-expr". This patch uses the existing dwarf-printing capabilities in lldb to enhance this dump output, and print the full decoded dwarf expression. Reviewers: jasonmolenda, clayborg Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D60949 llvm-svn: 358959
* Fix typo in ArmUnwindInfo::GetUnwindPlanRaphael Isemann2019-04-161-1/+1
| | | | | | | | | | | | | | | | | | | Summary: As reported in LLVM bug 41486, the check `(byte1 & 0xf8) == 0xc0` is wrong. We want to check for `11010nnn`, so the proper value we want to compare against is `0xd0` (`0xc0` would check for the value `11000nnn` which we already checked for above as described in the bug report). Reviewers: #lldb, jasonmolenda Reviewed By: #lldb, jasonmolenda Subscribers: jasonmolenda, javed.absar, kristof.beyls, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D60655 llvm-svn: 358479
* [NFC] Remove ASCII lines from commentsJonas Devlieghere2019-04-1016-115/+0
| | | | | | | | | | | | | | | | | | | | | | | A lot of comments in LLDB are surrounded by an ASCII line to delimit the begging and end of the comment. Its use is not really consistent across the code base, sometimes the lines are longer, sometimes they are shorter and sometimes they are omitted. Furthermore, it looks kind of weird with the 80 column limit, where the comment actually extends past the line, but not by much. Furthermore, when /// is used for Doxygen comments, it looks particularly odd. And when // is used, it incorrectly gives the impression that it's actually a Doxygen comment. I assume these lines were added to improve distinguishing between comments and code. However, given that todays editors and IDEs do a great job at highlighting comments, I think it's worth to drop this for the sake of consistency. The alternative is fixing all the inconsistencies, which would create a lot more churn. Differential revision: https://reviews.llvm.org/D60508 llvm-svn: 358135
* Remove the TypePair classPavel Labath2019-03-261-54/+36
| | | | | | | | | | | | | | | | Summary: After D59297, the TypePair class kind of lost its purpose as it was no longer a "pair". This finishes the job started in that patch and deletes the class altogether. All usages have been updated to use CompilerType class directly. Reviewers: clayborg, jingham, zturner Subscribers: mehdi_amini, dexonsmith, jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D59414 llvm-svn: 356993
* Remove the unused return value in ASTImporter::Imported [NFC]Raphael Isemann2019-03-201-3/+1
| | | | | | | | | | | | | | | | | | Summary: `ASTImporter::Imported` currently returns a Decl, but that return value is not used by the ASTImporter (or anywhere else) nor is it documented. Reviewers: balazske, martong, a.sidorin, shafik Reviewed By: balazske, martong Subscribers: rnkovacs, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D59595 llvm-svn: 356592
OpenPOWER on IntegriCloud