summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Language/CPlusPlus
Commit message (Collapse)AuthorAgeFilesLines
* Replace __ANDROID_NDK__ with __ANDROID__Pavel Labath2016-12-021-6/+1
| | | | | | | | | | | | | | | | | | | | Summary: This replaces all the uses of the __ANDROID_NDK__ define with __ANDROID__. This is a preparatory step to remove our custom android toolchain file and rely on the standard android NDK one instead, which does not provide this define. Instead I rely, on __ANDROID__, which is set by the compiler. I haven't yet removed the cmake variable with the same name, as we will need to do something completely different there -- NDK toolchain defines CMAKE_SYSTEM_NAME to Android, while our current one pretends it's linux. Reviewers: tberghammer, zturner Subscribers: danalbert, srhines, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D27305 llvm-svn: 288494
* [lldb] Fix typos in file headersAlexander Shaposhnikov2016-11-263-4/+3
| | | | | | | | | | | | | This diff fixes typos in file headers (incorrect file names). Test plan: Under llvm/tools/lldb/source: find ./* -type f | grep -e '\(cpp\|h\)$' | while read F; do B=$(basename $F); echo $F head -n 1 $F | grep -v $B | wc -l ; done Differential revision: https://reviews.llvm.org/D27115 llvm-svn: 287966
* Resubmit "Remove an output-parameter from Variable function".Zachary Turner2016-11-181-10/+12
| | | | | | | | | | | The scanning algorithm had a few little subtleties that I overlooked, but this patch should fix everything. I still haven't changed the function to take a StringRef since that has some trickle down effect and is mostly mechanical, I just wanted to get the tricky part as isolated as possible. llvm-svn: 287354
* Revert "Remove an out param from ValueObject::GetValueForExpressionPath."Zachary Turner2016-11-181-12/+10
| | | | | | | This reverts commit r287315, as it introduces a bug that breaks many things. llvm-svn: 287320
* Remove an out param from ValueObject::GetValueForExpressionPath.Zachary Turner2016-11-181-10/+12
| | | | | | | | | | This argument was only used in one place in the codebase, and it was in a non-critical log statement and can be easily substituted for an equally meaningful field instead. The payoff of computing this value is not worth the added complexity. llvm-svn: 287315
* Don't allow direct access to StreamString's internal buffer.Zachary Turner2016-11-167-10/+12
| | | | | | | | | | | | | | | This is a large API change that removes the two functions from StreamString that return a std::string& and a const std::string&, and instead provide one function which returns a StringRef. Direct access to the underlying buffer violates the concept of a "stream" which is intended to provide forward only access, and makes porting to llvm::raw_ostream more difficult in the future. Differential Revision: https://reviews.llvm.org/D26698 llvm-svn: 287152
* Display the pointer value in the libstdc++ unique_ptr summaryPavel Labath2016-11-091-16/+7
| | | | | | | | | | | | | | | | | | | Summary: r284830 added a summary provider for unique_ptr in libstdc++, whose value printed the value of the pointee. This is a bit unintuitive as it becomes unobvious that the value actually is a pointer, and we lose the way to actually obtain the pointer value. Change that to print the pointer value instead. The pointee value can still be obtained through the synthetic children. Reviewers: tberghammer, granata.enrico Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D26403 llvm-svn: 286355
* Simplify the PrintableRepresentationSpecialCases code; we never used the ↵Enrico Granata2016-11-073-3/+5
| | | | | | ePrintableRepresentationSpecialCasesOnly value and with enum classes the names doesn't need to be that long llvm-svn: 286176
* Implement a general type scavenger that can dig types from debug info + a ↵Enrico Granata2016-11-011-69/+10
| | | | | | | | | | filtering mechanism to accept/reject results thusly obtained Implement the C++ type lookup support in terms of this general scavenger The idea is that we may want other languages to do debug info based search (exclusively, or as an add-on to runtime/module based searching) and it makes sense to avoid duplicating this functionality llvm-svn: 285727
* Add support for "type lookup" to find C and C++ typesEnrico Granata2016-10-272-0/+78
| | | | | | | | This is an important first step in closing the functionality gap between "type lookup" and "images lookup -t" rdar://28971388 llvm-svn: 285332
* Revert "Improve the libstdc++ smart pointer formatters"Pavel Labath2016-10-253-201/+92
| | | | | | | This reverts commit r284828, as it causes an infinite loop in TestPrintStackTraces (funnily enough, only when logging is enabled). llvm-svn: 285068
* Fix incorrect header order introduced in rL284830Tamas Berghammer2016-10-212-6/+6
| | | | llvm-svn: 284831
* Add data formatter for libstdc++ unique_ptrTamas Berghammer2016-10-214-0/+180
| | | | | | Differential revision: https://reviews.llvm.org/D25734 llvm-svn: 284830
* Add data formatter for libstdc++ tupleTamas Berghammer2016-10-214-0/+119
| | | | | | Differential revision: https://reviews.llvm.org/D25733 llvm-svn: 284829
* Improve the libstdc++ smart pointer formattersTamas Berghammer2016-10-213-92/+201
| | | | | | | | | | * Display the strong/weak count in the summary * Display the pointed object as a synthetic member * Create synthetic children for weak/strong count Differential revision: https://reviews.llvm.org/D25726 llvm-svn: 284828
* Convert UniqueCStringMap to use StringRef.Zachary Turner2016-10-061-8/+10
| | | | llvm-svn: 283494
* Fixes for libc++ std::unordered_map data formatter against trunkEnrico Granata2016-10-051-4/+30
| | | | | | Fixes rdar://28237467 llvm-svn: 283396
* Fix the data formatter for std::multiset in libc++ - this is a trivial ↵Enrico Granata2016-10-041-25/+45
| | | | | | | | amount of extra change on top of multimap Also, proper formatting.. llvm-svn: 283167
* Changes to the std::multimap formatter to make it work against trunk libc++ Enrico Granata2016-10-031-10/+50
| | | | | | Fixes rdar://28237486 llvm-svn: 283160
* Fix an issue where libc++ changed the type information we get for ↵Enrico Granata2016-09-282-5/+65
| | | | | | | | std::map::iterator, rendering LLDB unable to display elements vended by an iterator Fixes <rdar://problem/28237521> llvm-svn: 282648
* Make lldb::Regex use StringRef.Zachary Turner2016-09-211-18/+24
| | | | | | | | | | This updates getters and setters to use StringRef instead of const char *. I tested the build on Linux, Windows, and OSX and saw no build or test failures. I cannot test any BSD or Android variants, however I expect the required changes to be minimal or non-existant. llvm-svn: 282079
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-0617-3454/+3368
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* Add a data formatter for std::function in libcxxEnrico Granata2016-08-313-0/+27
| | | | llvm-svn: 280295
* Fix parsing of complicated C++ namesPavel Labath2016-08-181-1/+3
| | | | | | | | | | | | | | | | Summary: CPlusPlusLanguage::MethodName was not correctly parsing templated functions whose demangled name included the return type -- the space before the function name was included in the "context" and the context itself was not terminated correctly due to a misuse of the substr function (second argument is length, not the end position). Fix that and add a regression test. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D23608 llvm-svn: 279038
* Fix an issue where the libc++ std::list formatter wasn't recognizing the new ↵Enrico Granata2016-07-191-2/+26
| | | | | | | | memory layout correctly rdar://problem/26999542 llvm-svn: 276061
* Fix the installation of the vector<bool> data formatters in order to restore ↵Enrico Granata2016-07-061-4/+2
| | | | | | functionality llvm-svn: 274697
* Because of our lifetime rules w.r.t. ValueObjects and ClusterManagers, ↵Enrico Granata2016-07-065-52/+16
| | | | | | | | | | | | | | | | synthetic children caching is a tricky area: - if a synthetic child comes from the same hierarchy as its parent object, then it can't be cached by SharedPointer inside the synthetic provider, or it will cause a reference loop; - but, if a synthetic child is made from whole cloth (e.g. from an expression, a memory region, ...), then it better be cached by SharedPointer, or it will be cleared out and cause an assert() to fail if used at a later point For most cases of self-rooted synthetic children, we have a flag we set "IsSyntheticChildrenGenerated", but we were not using it to track caching. So, what ended up happening is each provider would set up its own cache, and if it got it wrong, a hard to diagnose crash would ensue This patch fixes that by centralizing caching in ValueObjectSynthetic - if a provider returns a self-rooted child (as per the flag), then it gets cached centrally by the ValueObject itself This cache is used only for lifetime management and not later retrieval of child values - a different cache handles that (because we might have a mix of self-rooted and properly nested child values for the same parent, we can't trivially use this lifetime cache for retrieval) Fixes rdar://26480007 llvm-svn: 274683
* Add data formatter for libstdc++ shared_ptr and weak_ptrTamas Berghammer2016-07-063-22/+155
| | | | | | Differential revision: http://reviews.llvm.org/D21984 llvm-svn: 274617
* Fix the libc++ pretty printers for the android NDKTamas Berghammer2016-07-041-31/+39
| | | | | | | | | | | | The libc++ shipped with the android NDK is shipped using a different internal namespace then the upstream libc++ (__ndk1 vs. __1) to avoid an ODR violation between the platform and the user application. This change fixes our pretty printers to be able to work with the types from the android NDK libc++. Differential revision: http://reviews.llvm.org/D21680 llvm-svn: 274489
* Fix an issue where LLDB would crash if one tried to 'frame variable' an ↵Enrico Granata2016-05-251-4/+7
| | | | | | | | unordered_map more than once in a stop due to the synthetic provider not properly caching the ValueObjects it was returning for the child elements Fixes rdar://26470909 llvm-svn: 270752
* Import block pointers from DWARF as Clang block pointers, not as structs.Sean Callanan2016-05-024-0/+287
| | | | | | | | | Also added a data formatter that presents them as structs if you use frame variable to look at their contents. Now the blocks testcase works. <rdar://problem/15984431> llvm-svn: 268307
* Miscellaneous fixes for big-endian systemsUlrich Weigand2016-04-141-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes a bunch of issues that show up on big-endian systems: - The gnu_libstdcpp.py script doesn't follow the way libstdc++ encodes bit vectors: it should identify the enclosing *word* and then access the appropriate bit within that word. Instead, the script simply operates on bytes. This gives the same result on little-endian systems, but not on big-endian. - lldb_private::formatters::WCharSummaryProvider always assumes wchar_t is UTF16, even though it could also be UTF8 or UTF32. This is mostly not an issue on little-endian systems, but immediately fails on BE. Fixed by checking the size of wchar_t like WCharStringSummaryProvider already does. - ClangASTContext::GetChildCompilerTypeAtIndex uses uint32_t to access the virtual base offset stored in the vtable, even though the size of this field matches the target pointer size according to the C++ ABI. Again, this is mostly not visible on LE, but fails on BE. - Process::ReadStringFromMemory uses strncmp to search for a terminator consisting of multiple zero bytes. This doesn't work since strncmp will stop already at the first zero byte. Use memcmp instead. Differential Revision: http://reviews.llvm.org/D18983 llvm-svn: 266313
* Fixed being able to set breakpoints on destructors when we don't fully ↵Greg Clayton2016-04-121-1/+1
| | | | | | | | | | | | | | specify the demangled name. So all of the following now work: (lldb) b ~Foo (lldb) b Foo::~Foo (lldb) b Bar::Foo::~Foo Improved out C++ breakpoint locations tests as well to cover this issue. <rdar://problem/25577252> llvm-svn: 266139
* Remove what I believe are the last known instances of formatters that run codeEnrico Granata2016-04-081-6/+0
| | | | llvm-svn: 265865
* Fix Clang-tidy modernize-use-nullptr warnings in source/Plugins/Language; ↵Eugene Zelenko2016-02-298-162/+133
| | | | | | other minor fixes. llvm-svn: 262246
* Remove an unnecessary includeEnrico Granata2016-02-121-1/+0
| | | | llvm-svn: 260761
* Data formatter support for libc++ std::atomic<T>Enrico Granata2016-02-124-3/+156
| | | | | | | | | | On libc++ std::atomic is a fairly simple data type (layout wise, at least), wrapping actual contents in a member variable named "__a_" All the formatters are doing is "peel away" this intermediate layer and exposing user data as direct children or values of the std::atomic root variable Fixes rdar://24329405 llvm-svn: 260752
* Remove autoconf support from source directories.Eugene Zelenko2016-01-281-14/+0
| | | | | | Differential revision: http://reviews.llvm.org/D16662 llvm-svn: 259098
* Better scheme to lookup alternate mangled name when looking up function address.Siva Chandra2016-01-072-0/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This change is relevant for inferiors compiled with GCC. GCC does not emit complete debug info for std::basic_string<...>, and consequently, Clang (the LLDB compiler) does not generate correct mangled names for certain functions. This change removes the hard-coded alternate names in ItaniumABILanguageRuntime.cpp. Before the hard-coded names were put in ItaniumABILanguageRuntime.cpp, one could not evaluate std::string methods (ex. std::string::length). After putting in the hard-coded names, one could evaluate them. However, it did not still enable one to call methods on, say for example, std::vector<string>. This change makes that possible. There is some amount of incompleteness in this change. Consider the following example: std::string hello("hello"), world("world"); std::map<std::string, std::string> m; m[hello] = world; One can still not evaluate the expression "m[hello]" in LLDB. Will address this issue in another pass. Reviewers: jingham, vharron, evgeny777, spyffe, dawn Subscribers: clayborg, dawn, lldb-commits Differential Revision: http://reviews.llvm.org/D12809 llvm-svn: 257113
* Reduce memory traffic in ConstString in the std::map formatterEnrico Granata2015-12-041-6/+14
| | | | llvm-svn: 254787
* Do the same iterator caching optimization for std::mapEnrico Granata2015-12-041-48/+64
| | | | | | This brings the timings down for 1500 elements from 166 to 2 seconds on my machine - if I can math correctly, that is a 98% improvement llvm-svn: 254781
* Cache the incremental iterators as you traverse the list, so that you don't ↵Enrico Granata2015-12-041-64/+79
| | | | | | | | | | have to keep recomputing them If memory turns out to be a problem, which I don't think it will in practice because all these ValueObjects, we'd be keeping alive anyway, I can always resort to caching the farthest-most iterator only This gains us an order of magnitude in my benchmark, cutting the time to traverse a 1500-elements list from 22 seconds down to 2 llvm-svn: 254762
* Improve the std::list data formatter to not need to calculate indices for ↵Enrico Granata2015-12-041-3/+6
| | | | | | | | every loop iteration This saves about 5 seconds on a 1500 elements list from my local estimates llvm-svn: 254757
* Fix an issue where LLDB would truncate summaries for string types without ↵Enrico Granata2015-11-041-4/+21
| | | | | | producing any evidence thereof llvm-svn: 252018
* Remove two #if0ed regions of code that we were using for an experiment but ↵Enrico Granata2015-10-291-14/+0
| | | | | | don't really want llvm-svn: 251670
* Fix MSVC build after r251402Tamas Berghammer2015-10-271-1/+2
| | | | llvm-svn: 251403
* Some minor improvements on the symtab parsing codeTamas Berghammer2015-10-271-25/+45
| | | | | | | | | | | | | | | * Remove an unneccessary re-computaion on arch spec from the ELF file * Use a local cache to optimize name based section lookups in symtab parsing * Optimize C++ method basename validation with replacing a regex with hand written code These modifications reduce the time required to parse the symtab from large applications by ~25% (tested with LLDB as inferior) Differential revision: http://reviews.llvm.org/D14088 llvm-svn: 251402
* Fix libstdc++ data formatters on Ubuntu 15.10 x86_64Todd Fiala2015-10-223-7/+157
| | | | | | See http://reviews.llvm.org/D13964 for details. llvm-svn: 250965
* [DataFormatters] Make libc++ list loop detection linearPavel Labath2015-10-211-88/+113
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Loop detection code is being called before every element access. Although it tries to cache some of the data by remembering the loop-free initial segment, every time it needs to increase this segment, it will start from scratch. For the typical usage pattern, where one accesses the elements in order, the loop detection will need to be run after every access, resulting in quadratic behavior. This behavior is noticable even for the default 255 element limit. In this commit, I rewrite the algorithm to be truly incremental -- it maintains the state of its loop-detection runners between calls, and reuses them when it needs to check another segment. This way, each part of the list is scanned only once, resulting in linear behavior. Also note that I have changed the operator== of ListEntry to do the comparison based on the value() function (instead of relying on ValueObjectSP equality). In my experiments, I kept getting different ValueObjectSPs when going through the same element twice. Reviewers: granata.enrico Subscribers: lldb-commits, sivachandra Differential Revision: http://reviews.llvm.org/D13902 llvm-svn: 250890
* Fix Clang-tidy modernize-use-override warnings in source/Plugins/Language; ↵Eugene Zelenko2015-10-206-121/+129
| | | | | | | | other minor fixes. Differential Revision: http://reviews.llvm.org/D13876 llvm-svn: 250789
OpenPOWER on IntegriCloud