summaryrefslogtreecommitdiffstats
path: root/lldb/source/DataFormatters
Commit message (Collapse)AuthorAgeFilesLines
...
* LLGS Android target support - for Andy Chien : http://reviews.llvm.org/D6166Shawn Best2014-11-081-0/+3
| | | | llvm-svn: 221570
* This was meant to be count, not m_countEnrico Granata2014-11-071-1/+1
| | | | llvm-svn: 221541
* This is a large, but clearical, commit that enables the C++ formatters to ↵Enrico Granata2014-11-068-53/+56
| | | | | | take on the additional TypeSummaryOptions argument. It is still not used for anything, but it is now there. Adding support for this extra argument to Python formatters will follow suit llvm-svn: 221486
* Introduce the notion of "type summary options" as flags that can be passed ↵Enrico Granata2014-11-061-0/+44
| | | | | | | | | | | | | down to individual summary formatters to alter their behavior in a formatter-dependent way Two flags are introduced: - preferred display language (as in, ObjC vs. C++) - summary capping (as in, should a limit be put to the amount of data retrieved) The meaning - if any - of these options is for individual formatters to establish The topic of a subsequent commit will be to actually wire these through to individual data formatters llvm-svn: 221482
* Add a setting escape-non-printables that drives whether the StringPrinter ↵Enrico Granata2014-11-052-14/+28
| | | | | | | | | | | should or should not escape sequences such as \t, \n, .. and generally any non-printing character The recent StringPrinter changes made this behavior the default, and the setting defaults to yes If you want to change this behavior and see non-printables unescaped (e.g. "a\tb" as "a b"), set it to false Fixes rdar://12969594 llvm-svn: 221399
* for Siva Chandra: Fix compilation of StringPrinter.cpp with GCC. ↵Shawn Best2014-11-041-95/+105
| | | | | | Differential Revision: http://reviews.llvm.org/D6122 llvm-svn: 221310
* Remove #include <codecvt>. It isn't supported on all compilers.Zachary Turner2014-10-301-1/+0
| | | | | | Also it wasn't being used anyway, so it appears to be a dead include. llvm-svn: 220921
* Also port the C string reading code in ValueObject over to using ↵Enrico Granata2014-10-301-7/+18
| | | | | | StringPrinter API llvm-svn: 220917
* Fix CMake build, adding StringPrinter.cpp from r220894Ed Maste2014-10-301-0/+1
| | | | llvm-svn: 220909
* Start adopting the StringPrinter API. The StringPrinter API is the new ↵Enrico Granata2014-10-302-377/+686
| | | | | | blessed way of printing strings that supports escaping non-printables, and has better handling of different UTF encodings llvm-svn: 220894
* Fix the NSPathStore2 data formatter to actually handle the explicit length ↵Enrico Granata2014-10-291-1/+26
| | | | | | stored inside the object. The meat of this commit, however, is a nice little API for easily adding new __lldb_autogen_ helper types to an AST context llvm-svn: 220881
* Shuffle a couple of formatters around. This should fix the bug that never ↵Enrico Granata2014-10-291-12/+10
| | | | | | dies, aka rdar://15154623 llvm-svn: 220836
* More cleanup of the CXXFormatterFunctions headerEnrico Granata2014-10-222-0/+293
| | | | llvm-svn: 220433
* Fix CMake build broken after r220421.Zachary Turner2014-10-221-0/+2
| | | | llvm-svn: 220430
* Reorganize some of the data formatters code to simplify ↵Enrico Granata2014-10-227-103/+420
| | | | | | CXXFormattersFunction.h. Also, add a synthetic child provider for libc++'s version of std::initializer_list<T> llvm-svn: 220421
* Expose the type-info flags at the public API layer. These flags provide much ↵Enrico Granata2014-10-214-9/+9
| | | | | | more informational content to consumers of the LLDB API than the existing TypeClass. Part of the fix for rdar://18517593 llvm-svn: 220322
* Move anonymous types declared in an anonymous union toEric Christopher2014-10-211-91/+94
| | | | | | | outside the anonymous union as it's a language extension we don't normally support. llvm-svn: 220320
* Make a general helper function on the AST context to retrieve a type by ↵Enrico Granata2014-10-171-27/+11
| | | | | | identifier in the fashion needed by data formatters llvm-svn: 220059
* Rework this code so that it does not trigger a compiler warning. NFCEnrico Granata2014-10-161-9/+3
| | | | llvm-svn: 219964
* Remove unreachable code.Jason Molenda2014-10-161-4/+0
| | | | llvm-svn: 219911
* This should keep the non-Xcode-based builds happyEnrico Granata2014-10-151-0/+1
| | | | llvm-svn: 219853
* Add synthetic children support for NSIndexPathEnrico Granata2014-10-152-0/+308
| | | | llvm-svn: 219852
* The NSDate formatter should use GMT instead of the local timezone. Fixes ↵Enrico Granata2014-10-151-1/+1
| | | | | | rdar://13416848 llvm-svn: 219841
* Enhance the libc++ list data formatter so that it does not start looking for ↵Enrico Granata2014-10-091-7/+11
| | | | | | loops until asked to actually fetch children. Also, if you're going to read child X, only look for a loop in the first X nodes. Loops further down the road won't really matter. This should speed things up for large lists and fix rdar://18583790 llvm-svn: 219447
* If a ValueObject has a child that vends synthetic children, but only does so ↵Enrico Granata2014-10-092-5/+15
| | | | | | to generate a value for itself, that's not a disqualifier from one-line printing. Also, fetch synthetic values if available and requested for children as well while printing them llvm-svn: 219427
* Extend synthetic children to produce synthetic values (as in, those that ↵Enrico Granata2014-10-082-10/+34
| | | | | | | | | | | | | | | | | GetValueAsUnsigned(), GetValueAsCString() would return) The way to do this is to write a synthetic child provider for your type, and have it vend the (optional) get_value function. If get_value is defined, and it returns a valid SBValue, that SBValue's value (as in lldb_private::Value) will be used as the synthetic ValueObject's Value The rationale for doing things this way is twofold: - there are many possible ways to define a "value" (SBData, a Python number, ...) but SBValue seems general enough as a thing that stores a "value", so we just trade values that way and that keeps our currency trivial - we could introduce a new level of layering (ValueObjectSyntheticValue), a new kind of formatter (synthetic value producer), but that would complicate the model (can I have a dynamic with no synthetic children but synthetic value? synthetic value with synthetic children but no dynamic?), and I really couldn't see much benefit to be reaped from this added complexity in the matrix On the other hand, just defining a synthetic child provider with a get_value but returning no actual children is easy enough that it's not a significant road-block to adoption of this feature Comes with a test case llvm-svn: 219330
* The type category enable * was implemented assuming a previous disable * had ↵Enrico Granata2014-10-071-2/+17
| | | | | | happened. While that will most likely be true in practice, the consequences of this not being the case will be a crash. I fix the crash by doing two things: 1) don't let already-enabled categories be enabled anyway; 2) if a category were disabled but with a bogus last-enabled position - highly highly unlikely - just put it in the first empty slot. I am not so sure 2) is bulletproof perfect, but I also don't think 2) will practically ever happen llvm-svn: 219245
* Stop enabling the std::vector<bool> data formatter for libstdc++, and for ↵Enrico Granata2014-10-031-7/+0
| | | | | | that matter, also skip running the test on Darwin. libstdc++ is more relevant on non-Apple platforms llvm-svn: 218952
* Issuing a "type category disable *" command followed by a "type category ↵Enrico Granata2014-10-033-2/+39
| | | | | | | | | | enable *" command does not honor the order in which categories were previously enabled While we didn't really promise it would, it seems like it should This checkin enables just that, and fixes rdar://18527468 llvm-svn: 218949
* Unused functions break the -Werror build. Revert for now.Enrico Granata2014-09-161-9/+0
| | | | llvm-svn: 217900
* Add a convenience function to FormatManager to setup an empty filter (one ↵Enrico Granata2014-09-161-0/+9
| | | | | | that suppresses all children, that is) llvm-svn: 217891
* Fix the ctor ivar initialization formatting for Debugger,Jason Molenda2014-09-121-3/+3
| | | | | | | TypeValidatorImpl, FileAction, and ProcessLaunchInfo to match the lldb coding convention. llvm-svn: 217653
* Recent builds of libcxx actually wrap an std::map's children values in a ↵Enrico Granata2014-09-121-1/+29
| | | | | | union containing either a member named __cc, or either of __cc and __nc (const vs. non-const). This level of wrapping is quite useless for LLDB to show to people, so try to detect it, and filter it out llvm-svn: 217651
* When deciding if one-liner printing applies, and you find a summary, the ↵Enrico Granata2014-09-111-3/+2
| | | | | | summary is a good candidate to ask. While in theory one could want one-liner printing with a non-one-liner summary, I don't see LLDB as the best place to solve such inner conflicts llvm-svn: 217641
* DataFormatters: add missing destructor implementationSaleem Abdulrasool2014-09-081-0/+4
| | | | | | | The last of the missing symbols to correct the make based build to restore the FreeBSD buildbot! llvm-svn: 217394
* DataFormatters: add missing function implementationsSaleem Abdulrasool2014-09-081-0/+10
| | | | | | | | | | | | | This adds a definition for the TypeValidatorImpl_CXX destructor. Because the destructor is first virtual method, and declared out-of-line, it also serves as the key function. Since no definition was present, no virtual table for TypeValidatorImpl_CXX was emitted, which results in link failures due to references to undefined symbols. Also add a definition for a TypeValidatorImpl contructor which was declared out-of-line and referenced in a constructor for TypeValidatorImpl_CXX. llvm-svn: 217375
* DataFormatters: use include instead of import in C++Saleem Abdulrasool2014-09-071-1/+1
| | | | | | | | | | '#import' is an Objective-C construct; avoid using it in C++. NFC. Addresses PR20867. Patch by Kevin Avila! llvm-svn: 217340
* Add a -V <bool> flag to frame variable/expression that enables execution of ↵Enrico Granata2014-09-061-0/+45
| | | | | | type validators. The jury is still out on what the user experience of type validators should be, so for now gate it on a specific flag. The mode I am using is prefix variables that fail to validate with a bang, and then emitting the actual validation error on a separate line. Of course, given the total absence of validators, this should never actually happen to you llvm-svn: 217303
* Start plumbing the type validator logic through to the ValueObjects; allow a ↵Enrico Granata2014-09-051-2/+2
| | | | | | ValueObject to have a validator, to update it from the FormatManager, and to retrieve (and cache) the result of the validation llvm-svn: 217282
* Add TypeValidator.cpp to cmake build.Todd Fiala2014-09-051-0/+1
| | | | llvm-svn: 217280
* Introduce the notion of a "type validator" formatterEnrico Granata2014-09-056-6/+353
| | | | | | | | | | Type Validators have the purpose of looking at a ValueObject, and making sure that there is nothing semantically wrong about the object's contents For instance, if you have a class that represents a speed, the validator might trigger if the speed value is greater than the speed of light This first patch hooks up the moving parts in the formatters subsystem, but does not link ValueObjects to TypeValidators, nor lets the SB API be exposed to validators It also lacks the notion of Python validators llvm-svn: 217277
* Add __NSCFDictionary to the list of NSDictionary-like types for which we ↵Enrico Granata2014-08-271-0/+1
| | | | | | know to generate synthetic children llvm-svn: 216513
* Refactor the hardcoded formatters facility to use sequences of lambdas - ↵Enrico Granata2014-08-191-16/+55
| | | | | | still no feature change as none are present now, but this feels cleaner. Also, hardcoded formatters do not need to be per-type, so disable caching thereof llvm-svn: 216004
* Enable the data formatter for std::vector<bool> on libc++ again. In recent ↵Enrico Granata2014-08-161-0/+2
| | | | | | clang builds, we are vended a different typename, which the formatter needs to match against. llvm-svn: 215801
* Improve the way the ObjC data formatters fetch a valid frame to use for ↵Enrico Granata2014-07-302-5/+25
| | | | | | | | | | running expressions against This is not bullet-proof, as you might end up running in a thread where you shouldn't, but the previous policy had the same drawback Also, in cases where code-running formatters were being recursively applied, the previous policy caused deeper levels to fail, whereas this will at least get such scenarios to function We might eventually want to consider disqualifying certain threads/frames for "viability", but I'd rather keep it simple until complexity is proven to be necessary llvm-svn: 214337
* TypeSynthetic: Fix a pointer-to-function to void-pointer castDavid Majnemer2014-07-221-1/+1
| | | | | | | | | | reinterpret_cast may not convert a pointer-to-function to a void-pointer. Take a detour through intptr_t and *then* convert to a pointer-to-function. Differential Revision: http://reviews.llvm.org/D4627 llvm-svn: 213682
* Fixes for broken Debian build - g++ 4.7 support.Todd Fiala2014-07-101-0/+11
| | | | | | | | | | | | | | | | | | | | | | | | These fix the broken debian lldb build, which is using g++ 4.7.2. TypeFormat changes: 1. stopped using the C++11 "dtor = default;" construct. The generated default destructor in the two derived classes wanted them to have a different throws() semantic that was causing 4.7 to fail to generate it. I switched these to empty destructors defined in the .cpp file. 2. Switched the m_types map from an ordered map to an unordered_map. g++ 4.7's c++ library supports the C++11 emplace() used by TypeFormat but the same c++ library's map impl does not. Since TypeFormat didn't look like it depended on ordering in the map, I just switched it to a std::unordered_map. NativeProcessLinux - g++ 4.7 chokes on lexing the "<::" in static_cast<::pid_t>(wpid). g++ 4.8+ and clang are fine with it. I just put a space in between the "<" and the "::" and that cleared it up. llvm-svn: 212681
* lldb: remove adhoc implementation of array_sizeofSaleem Abdulrasool2014-06-271-2/+2
| | | | | | | | Replace adhoc inline implementation of llvm::array_lengthof in favour of the implementation in LLVM. This is simply a cleanup change, no functional change intended. llvm-svn: 211868
* Initial merge of some of the iOS 8 / Mac OS X Yosemite specificJason Molenda2014-06-132-23/+417
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | lldb support. I'll be doing more testing & cleanup but I wanted to get the initial checkin done. This adds a new SBExpressionOptions::SetLanguage API for selecting a language of an expression. I added adds a new SBThread::GetInfoItemByPathString for retriving information about a thread from that thread's StructuredData. I added a new StructuredData class for representing key-value/array/dictionary information (e.g. JSON formatted data). Helper functions to read JSON and create a StructuredData object, and to print a StructuredData object in JSON format are included. A few Cocoa / Cocoa Touch data formatters were updated by Enrico to track changes in iOS 8 / Yosemite. Before we query a thread's extended information, the system runtime may provide hints to the remote debug stub that it will use to retrieve values out of runtime structures. I added a new SystemRuntime method AddThreadExtendedInfoPacketHints which allows the SystemRuntime to add key-value type data to the initial request that we send to the remote stub. The thread-format formatter string can now retrieve values out of a thread's extended info structured data. The default thread-format string picks up two of these - thread.info.activity.name and thread.info.trace_messages. I added a new "jThreadExtendedInfo" packet in debugserver; I will add documentation to the lldb-gdb-remote.txt doc soon. It accepts JSON formatted arguments (most importantly, "thread":threadnum) and it returns a variety of information regarding the thread to lldb in JSON format. This JSON return is scanned into a StructuredData object that is associated with the thread; UI layers can query the thread's StructuredData to see if key-values are present, and if so, show them to the user. These key-values are likely to be specific to different targets with some commonality among many targets. For instance, many targets will be able to advertise the pthread_t value for a thread. I added an initial rough cut of "thread info" command which will print the information about a thread from the jThreadExtendedInfo result. I need to do more work to make this format reasonably. Han Ming added calls into the pmenergy and pmsample libraries if debugserver is run on Mac OS X Yosemite to get information about the inferior's power use. I added support to debugserver for gathering the Genealogy information about threads, if it exists, and returning it in the jThreadExtendedInfo JSON result. llvm-svn: 210874
* Introduce the concept of a "display name" for typesEnrico Granata2014-05-172-2/+10
| | | | | | | | | | | | | | | | | | | | | | Rationale: Pretty simply, the idea is that sometimes type names are way too long and contain way too many details for the average developer to care about. For instance, a plain ol' vector of int might be shown as std::__1::vector<int, std::__1::allocator<.... rather than the much simpler std::vector<int> form, which is what most developers would actually type in their code Proposed solution: Introduce a notion of "display name" and a corresponding API GetDisplayTypeName() to return such a crafted for visual representation type name Obviously, the display name and the fully qualified (or "true") name are not necessarily the same - that's the whole point LLDB could choose to pick the "display name" as its one true notion of a type name, and if somebody really needs the fully qualified version of it, let them deal with the problem Or, LLDB could rename what it currently calls the "type name" to be the "display name", and add new APIs for the fully qualified name, making the display name the default choice The choice that I am making here is that the type name will keep meaning the same, and people who want a type name suited for display will explicitly ask for one It is the less risky/disruptive choice - and it should eventually make it fairly obvious when someone is asking for the wrong type Caveats: - for now, GetDisplayTypeName() == GetTypeName(), there is no logic to produce customized display type names yet. - while the fully-qualified type name is still the main key to the kingdom of data formatters, if we start showing custom names to people, those should match formatters llvm-svn: 209072
OpenPOWER on IntegriCloud