summaryrefslogtreecommitdiffstats
path: root/lldb/examples/synthetic/libcxx.py
Commit message (Collapse)AuthorAgeFilesLines
* Fix typos.Bruce Mitchener2015-09-221-2/+2
| | | | | | | | | | | | Summary: Another round of minor typo fixes. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13026 llvm-svn: 248243
* Quick fix for the libc++ std::map synthetic children providerEnrico Granata2013-02-091-2/+6
| | | | | | | | If you try to access any child > 0 without having touched child 0, LLDB won't be able to reconstruct type information from the debug info. Previously, we would fail. Now, we simply go fetch child 0 and then come back. llvm-svn: 174795
* <rdar://problem/12239827>Enrico Granata2013-01-121-0/+3
| | | | | | Making a summary for std::wstring as provided by libstdc++ along with a relevant test case llvm-svn: 172286
* <rdar://problem/12848118>Enrico Granata2012-12-101-24/+3
| | | | | | | Making MightHaveChildren() always return true regardless for our own data formatters This is meant to optimize performance for common most-often-not-empty container classes llvm-svn: 169759
* <rdar://problem/12523238> Commit 2 of 3Enrico Granata2012-10-231-0/+37
| | | | | | | | | | | Adding the new has_children (or MightHaveChildren() in C++) for the existing synthetic children providers In a few cases, the new call is going to be much more efficient than the previous num_children > 0 check When the optimization was marginal (e.g. std::vector<>), the choice was to use num_children in order to keep implementation details in one function instead of duplicating code Next step is to provide test cases llvm-svn: 166506
* Making sure to create the count attribute in synthetic children providers ↵Enrico Granata2012-09-131-0/+2
| | | | | | for libcxx at the right time llvm-svn: 163823
* Data formatters for libc++ deque and shared/weak ptrs - a contribution by ↵Enrico Granata2012-08-271-2/+187
| | | | | | Jared Grubb llvm-svn: 162680
* Returning data formatters to their previous working condition - Plus fixing ↵Enrico Granata2012-04-251-50/+50
| | | | | | an issue that was preventing Python oneliners from executing llvm-svn: 155563
* Fixing an over-substitution of textEnrico Granata2012-04-251-50/+50
| | | | llvm-svn: 155556
* Make the C++ formatters importable by having them use the right package to ↵Enrico Granata2012-04-251-51/+51
| | | | | | import and reference the Logger llvm-svn: 155555
* Making sure the count on synthetic providers is always setup - This should ↵Enrico Granata2012-03-311-2/+2
| | | | | | prevent errors about count being undefined from showing up llvm-svn: 153791
* Added some logging to STL synthetic children providers - this should help us ↵Enrico Granata2012-03-301-2/+8
| | | | | | catch problems; more logging might/will be added as needed llvm-svn: 153750
* Part 1 of a series of fixes meant to improve reliability and increase ease ↵Enrico Granata2012-03-291-3/+91
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | of bug fixing for data formatter issues. We are introducing a new Logger class on the Python side. This has the same purpose, but is unrelated, to the C++ logging facility The Pythonic logging can be enabled by using the following scripting commands: (lldb) script Logger._lldb_formatters_debug_level = {0,1,2,...} 0 = no logging 1 = do log 2 = flush after logging each line - slower but safer 3 or more = each time a Logger is constructed, log the function that has created it more log levels may be added, each one being more log-active than the previous by default, the log output will come out on your screen, to direct it to a file: (lldb) script Logger._lldb_formatters_debug_filename = 'filename' that will make the output go to the file - set to None to disable the file output and get screen logging back Logging has been enabled for the C++ STL formatters and for Cocoa class NSData - more logging will follow synthetic children providers for classes list and map (both libstdcpp and libcxx) now have internal capping for safety reasons this will fix crashers where a malformed list or map would not ever meet our termination conditions to set the cap to a different value: (lldb) script {gnu_libstdcpp|libcxx}.{map|list}_capping_size = new_cap (by default, it is 255) you can optionally disable the loop detection algorithm for lists (lldb) script {gnu_libstdcpp|libcxx}.list_uses_loop_detector = False llvm-svn: 153676
* Synthetic values are now automatically enabled and active by default. ↵Enrico Granata2012-03-271-0/+2
| | | | | | | | | | | | SBValue is set up to always wrap a synthetic value when one is available. A new setting enable-synthetic-value is provided on the target to disable this behavior. There also is a new GetNonSyntheticValue() API call on SBValue to go back from synthetic to non-synthetic. There is no call to go from non-synthetic to synthetic. The test suite has been changed accordingly. Fallout from changes to type searching: an hack has to be played to make it possible to use maps that contain std::string due to the special name replacement operated by clang Fixing a test case that was using libstdcpp instead of libc++ - caught as a consequence of said changes to type searching llvm-svn: 153495
* Massive enumeration name changes: a number of enums in ValueObject were not ↵Enrico Granata2012-03-191-3/+3
| | | | | | | | | | | | | | | | | | following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
* Added formatters for libc++ (http://libcxx.llvm.org):Enrico Granata2012-03-121-0/+481
std::string has a summary provider std::vector std::list and std::map have both a summary and a synthetic children provider Given the usage of a custom namespace (std::__1::classname) for the implementation of libc++, we keep both libstdcpp and libc++ formatters enabled at the same time since that raises no conflicts and enabled for seamless transition between the two The formatters for libc++ reside in a libcxx category, and are loaded from libcxx.py (to be found in examples/synthetic) The formatters-stl test cases have been divided to be separate for libcxx and libstdcpp. This separation is necessary because (a) we need different compiler flags for libc++ than for libstdcpp (b) libc++ inlines a lot more than libstdcpp and some code changes were required to accommodate this difference llvm-svn: 152570
OpenPOWER on IntegriCloud