summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Language/CPlusPlus
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Enable the StringPrinter to have prefixes that are strings instead of just a ↵Enrico Granata2015-10-072-7/+7
| | | | | | single character; and also introduce a comparable suffix mechanism llvm-svn: 249506
* Fix evaluation of unicode character arrays (char16_t[] and char32_t[])Dawn Perchik2015-09-252-15/+20
| | | | | | | | | | | | | | | | Suppose we have the UTF-16 string: char16_t[] s = u"hello"; Before this patch, evaluating the string in lldb would get: (char16_t [6]) $0 = ([0] = U+0068 u'h', [1] = U+0065 u'e', [2] = U+006c u'l', [3] = U+006c u'l', [4] = U+006f u'o', [5] = U+0000 u'\0') After applying the patch, we now get: (char16_t [6]) $0 = u"hello" Patch from evgeny.leviant@gmail.com Reviewed by: granata.enrico Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13053 llvm-svn: 248555
* Rename clang_type -> compiler_type for variables.Bruce Mitchener2015-09-241-3/+3
| | | | | | | | | | Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13102 llvm-svn: 248461
* Move hardcoded formatters from the FormatManager to the Language pluginsEnrico Granata2015-09-162-0/+79
| | | | llvm-svn: 247831
* Introduce the notion of an escape helper. Different languages have different ↵Enrico Granata2015-09-092-20/+20
| | | | | | | | notion of what to print in a string and how to escape non-printable things. The escape helper is where this notion is provided to LLDB This is NFC, other than a code re-org llvm-svn: 247200
* Preparatory work for letting language plugins help the StringPrinter with ↵Enrico Granata2015-09-092-12/+12
| | | | | | formatting special characters llvm-svn: 247189
* Fix Makefile buildKeno Fischer2015-09-051-0/+14
| | | | llvm-svn: 246932
OpenPOWER on IntegriCloud