summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Language/CPlusPlus
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Never mind, I see what the problem is on the Windows build. Attempt a fixEnrico Granata2015-09-041-1/+0
| | | | llvm-svn: 246876
* Move the C++ data formatters to the C++ language pluginEnrico Granata2015-09-0414-3/+2854
| | | | llvm-svn: 246873
* [cmake] Remove LLVM_NO_RTTI.Bruce Mitchener2015-09-031-2/+0
| | | | | | | | | | | | | | Summary: This doesn't exist in other LLVM projects any longer and doesn't do anything. Reviewers: chaoren, labath Subscribers: emaste, tberghammer, lldb-commits, danalbert Differential Revision: http://reviews.llvm.org/D12586 llvm-svn: 246749
* Move more functionality from the LanguageRuntimes to the Languages.Jim Ingham2015-09-022-0/+491
| | | | llvm-svn: 246616
* Use Language::LanguageIsCPlusPlus instead of doing the same switch over languageEnrico Granata2015-09-021-10/+3
| | | | llvm-svn: 246613
* Add a new type of plugin: Language pluginEnrico Granata2015-08-273-0/+139
The Language plugin is menat to answer language-specific questions that are not bound to the existence of a process. Those are still the domain of the LanguageRuntime plugin The Language plugin will, instead, answer questions such as providing language-specific data formatters or expression evaluation At the moment, the interface is hollowed out, and empty do-nothing plugins have been setup for ObjC, C++ and ObjC++ llvm-svn: 246212
OpenPOWER on IntegriCloud