summaryrefslogtreecommitdiffstats
path: root/lldb/source/DataFormatters
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Rename eExecution*** to eExpression*** to be consistent with the result type.Jim Ingham2014-05-051-2/+2
| | | | llvm-svn: 207945
* Allow summary formatters to take ValueObjects into account when deciding ↵Enrico Granata2014-04-233-13/+13
| | | | | | | | whether values/children should be printed and if child names should be shown This decision has always been statically-bound to the individual formatter. With this patch, the idea is that this decision could potentially be dynamic depending on the ValueObject itself llvm-svn: 207046
* <rdar://problem/16540961>Enrico Granata2014-04-101-4/+2
| | | | | | | | The "unexpected value" message only matters to me, but is bound to make the experience more confusing for people when some uninitialized memory looks like an NSNumber and then can't be formatted properly, and that error comes out in the UI Just drop the error message entirely - nobody but me cares llvm-svn: 205978
* <rdar://problem/12055586>Enrico Granata2014-04-101-3/+29
| | | | | | | | Enable data formatters to see-through pointers/references to typedefs For instance, if Foo is a typedef to Bar, and there is a formatter for any/all of Bar*, Bar&, Bar&&, then Foo*, Foo&, and Foo&& should pick these up if Foo-specific formatters don't exist llvm-svn: 205939
* sweep up -Wformat warnings from gccSaleem Abdulrasool2014-04-043-6/+13
| | | | | | | This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
* sanitise sign comparisonsSaleem Abdulrasool2014-04-021-1/+1
| | | | | | | | This is a mechanical change addressing the various sign comparison warnings that are identified by both clang and gcc. This helps cleanup some of the warning spew that occurs during builds. llvm-svn: 205390
* <rdar://problem/16424592>Enrico Granata2014-03-311-3/+1
| | | | | | | | For some reason, the libc++ vector<bool> data formatter was essentially a costly no-up, doing everything required of it, except actually generating the child values! This restores its functionality llvm-svn: 205259
* cleanup unreferenced functionsSaleem Abdulrasool2014-03-201-22/+0
| | | | | | | | | | | | | This is a mechanical cleanup of unused functions. In the case where the functions are referenced (in comment form), I've simply commented out the functions. A second pass to clean that up is warranted. The functions which are otherwise unused have been removed. Some of these were introduced in the initial commit and not in use prior to that point! NFC llvm-svn: 204310
* rdar://16361422Enrico Granata2014-03-201-0/+1
| | | | | | Add NSMutableData to the list of types that the NSData formatter knows to represent llvm-svn: 204289
* Fix Windows build using portable types for formatting the log outputsDeepak Panickal2014-03-038-18/+16
| | | | llvm-svn: 202723
* Better error reporting when a variable can't beSean Callanan2014-02-285-11/+53
| | | | | | | | | | | read during materialization. First of all, report if we can't read the data for some reason. Second, consult the ValueObject's error and report that if there's some problem. <rdar://problem/16074201> llvm-svn: 202552
* <rdar://problem/15593026>Enrico Granata2014-02-251-18/+30
| | | | | | Fix the algorithm used to detect a loop in a std::list llvm-svn: 202205
* <rdar://problem/16006373>Enrico Granata2014-02-151-9/+9
| | | | | | | Revert the spirit of r199857 - a convincing case can be made that overriding a summary's format markers behind its back is not the right thing to do This commit reverts the behavior of the code to the previous model, and changes the test case to validate the opposite of what it was validating before llvm-svn: 201455
* rdar://15648942Enrico Granata2014-02-071-0/+19
| | | | | | | Provide a filter for libc++ std::atomic<T> This just hides some implementation clutter and promotes the actual content to only child status llvm-svn: 200984
* <rdar://problem/15154623>Enrico Granata2014-02-031-3/+3
| | | | | | Move a couple formatters from category AppKit to CoreFoundation llvm-svn: 200713
* Merging the iohandler branch back into main. Greg Clayton2014-01-271-1/+2
| | | | | | | | | | | | The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
* <rdar://problem/15776874>Enrico Granata2014-01-271-3/+2
| | | | | | | | ValueObjectPrinter could enter an infinite loop while trying to display an aptly formed ValueObject: a reference, with a child of some pointer type, such that the pointees chain ended up pointing back to some part of itself - a pointer to itself being the simplest such case Fixed here by only setting a pointer depth when needed, and ensuring that we won't overflow and wrap the pointer depth when it's zero. llvm-svn: 200247
OpenPOWER on IntegriCloud