| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
| |
llvm-svn: 198724
|
|
|
|
|
|
|
|
|
|
|
| |
The "type format add" command gets a new flag --type (-t). If you pass -t <sometype>, upon fetching the value for an object of your type,
LLDB will display it as-if it was of enumeration type <sometype>
This is useful in cases of non-contiguous enums where there are empty gaps of unspecified values, and as such one cannot type their variables as the enum type,
but users would still like to see them as-if they were of the enum type (e.g. DWARF field types with their user-reserved ranges)
The SB API has also been improved to handle both types of formats, and a test case is added
llvm-svn: 198105
|
|
|
|
|
|
|
|
|
| |
possible formatters matches is now done elsewhere
So, rename the class for what it truly is: a FormattersContainer
Also do a bunch of related text substitutions in the interest of overall naming clarity
llvm-svn: 197795
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Rework data formatters matching algorithm
What happens now is that, for each category, the FormatNavigator generates all possible matches, and checks them one by one
Since the possible matches do not actually depend on the category (whether a match is accepted or not does, but that check can be shifted at a more convenient time),
it is actually feasible to generate every possible match upfront and then let individual categories just scan through those
This commit changes things by introducing a notion of formatters match candidate, and shifting responsibility for generating all of them given a (ValueObject,DynamicValueType) pair
from the FormatNavigator back to the FormatManager
A list of these candidates is then passed down to each category for matching
Candidates also need to remember whether they were generated by stripping pointers, references, typedefs, since this is something that individual formatters can choose to reject
This check, however, is conveniently only done once a "textual" match has been found, so that the list of candidates is truly category-independent
While the performance benefit is small (mostly, due to caching), this is much cleaner from a design perspective
llvm-svn: 195395
|
|
|
|
|
|
| |
auto-one-line-summaries
llvm-svn: 193801
|
|
|
|
|
|
|
|
|
|
|
|
| |
bind to a ValueObject internally depending on any criteria
User-vended by-type formatters still would prevail on these hardcoded ones
For the time being, while the infrastructure is there, no such formatters exist
This can be useful for cases such as expanding vtables for C++ class pointers, when there is no clear cut notion of a typename matching, and the feature is low-level enough that it makes sense for the debugger core to be vending it
llvm-svn: 193724
|
|
|
|
|
|
|
| |
CFNumberRef is toll-free bridged to NSNumber
We can use the same summary formatter for both types
llvm-svn: 193666
|
|
|
|
|
|
|
|
|
|
| |
Introduce a new boolean setting enable-auto-oneliner
This setting if set to false will force LLDB to not use the new compact one-line display
By default, one-line mode stays on, at least until we can be confident it works.
But now if it seriously impedes your workflow while it evolves/it works wonders but you still hate it, there's a way to turn it off
llvm-svn: 193450
|
|
|
|
|
|
|
|
|
|
|
|
| |
they are not the base class
This check was overly strict. Relax it.
While one could conceivably want nested one-lining:
(Foo) aFoo = (x = 1, y = (t = 3, q = “Hello), z = 3.14)
the spirit of this feature is mostly to make *SMALL LINEAR* structs come out more compact.
Aggregates with children and no summary for now just disable the one-lining. Define a one-liner summary to override :)
llvm-svn: 193218
|
|
|
|
|
|
|
|
| |
remove
Hopefully nobody had a struct Foo in their app:-)
llvm-svn: 193092
|
|
|
|
| |
llvm-svn: 193053
|
|
|
|
|
|
| |
formats as well as summaries and synthetics
llvm-svn: 192928
|
|
|
|
|
|
|
|
|
| |
Extend DummySyntheticProvider to actually use debug-info vended children as the source of information
Make Python synthetic children either be valid, or fallback to the dummy, like their C++ counterparts
This allows LLDB to actually stop bailing out upon encountering an invalid synthetic children provider front-end, and still displaying the non synthetized ivar info
llvm-svn: 192741
|
|
|
|
|
|
|
|
| |
Add a format for FourCharCode
This is now safe to do thanks to the "formats in categories" feature
llvm-svn: 192233
|
|
|
|
|
|
|
| |
Formats (as in "type format") are now included in categories
The only bit missing is caching formats along with synthetic children and summaries, which might be now desirable
llvm-svn: 192217
|
|
|
|
|
|
|
| |
Several CF* data formatters were in the AppKit category
This puts them back where they belong, i.e. in category CoreFoundation
llvm-svn: 192008
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This radar extends the notion of one-liner summaries to automagically apply in a few interesting cases
More specifically, this checkin changes the printout of ValueObjects to print on one-line (as if type summary add -c had been applied) iff:
this ValueObject does not have a summary
its children have no synthetic children
its children are not a non-empty base class without a summary
its children do not have a summary that asks for children to show up
the aggregate length of all the names of all the children is <= 50 characters
you did not ask to see the types during a printout
your pointer depth is 0
This is meant to simplify the way LLDB shows data on screen for small structs and similarly compact data types (e.g. std::pair<int,int> anyone?)
Feedback is especially welcome on how the feature feels and corner cases where we should apply this printout and don't (or viceversa, we are applying it when we shouldn't be)
llvm-svn: 191996
|
|
|
|
|
|
|
|
| |
SVN r189964 provided a sample Python script to inspect unordered(multi){set|map} with synthetic children, contribued by Jared Grubb
This checkin converts that sample script to a C++ provider built into LLDB
A test case is also provided
llvm-svn: 190564
|
|
|
|
| |
llvm-svn: 187900
|
|
|
|
| |
llvm-svn: 186023
|
|
|
|
|
|
|
|
| |
for a while now and has not caused issues that warrant disabling it
Also, print the cache hits statistics if the log is in debugging mode vs. LLDB being a debug build - this should make it easier to gather useful metrics on cache success rate for real users
llvm-svn: 184900
|
|
|
|
|
|
|
| |
Modifying our data formatters matching algorithm to ensure that "const X*" is treated as equivalent to "X*"
Also, a couple improvements to the "lldb types" logging
llvm-svn: 184215
|
|
|
|
|
|
| |
the byte size will tell us how to display it.
llvm-svn: 183755
|
|
|
|
|
|
|
|
|
|
| |
Add support for half-floats, as specified by IEEE-754-2008
With this checkin, you can now say:
(lldb) x/7hf foo
to read 7 half-floats at address foo
llvm-svn: 183716
|
|
|
|
|
|
|
| |
Adding data formatters for std::set, std::multiset and std::multimap for libc++
The underlying data structure is the same as std::map, so this change is very minimal and mostly consists of test cases
llvm-svn: 183323
|
|
|
|
|
|
| |
Formatters for unsigned char* and const variant
llvm-svn: 183254
|
|
|
|
|
|
| |
Make a summary format for libc++ STL containers that shows the number of items as before, but also shows the pointer value for pointer-to-container
llvm-svn: 181236
|
|
|
|
|
|
| |
Synthetic children provider for NSOrderedSet
llvm-svn: 180655
|
|
|
|
| |
llvm-svn: 180588
|
|
|
|
|
|
|
|
|
| |
http://stackoverflow.com/questions/16166897/c-how-to-obtain-address-of-stdvector-object-in-lldb-xcode
The user was trying to obtain the address-of an std::vector and the experience was more painful than necessary because data formatters were kicking in for vector* objects
We got this right for libc++ - we should get it right for libstdc++ too
llvm-svn: 180219
|
|
|
|
|
|
| |
Making sure that CF*{Array|Dictionary}Ref provide synthetic children correctly.
llvm-svn: 180074
|
|
|
|
|
|
|
| |
By default, omit the children for a char[] and just show the string contents
Can be overridden by appropriate command-line flags
llvm-svn: 178292
|
|
|
|
|
|
|
|
| |
LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.
All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down.
llvm-svn: 178191
|
|
|
|
|
|
|
|
| |
and std::map as provided by libc++ are now written in C++ instead of Python
std::deque is still in Python but is much less commonly used
llvm-svn: 177454
|
|
|
|
|
|
| |
Python and reimplements them in C++. The Python Cocoa formatters are not shipped as part of LLDB anymore, but still exist in the source repository for user reference. Python formatters still exist for STL classes and users can still define their own Python formatters
llvm-svn: 177366
|
|
|
|
| |
llvm-svn: 177219
|
|
|
|
| |
llvm-svn: 177217
|
|
|
|
|
|
| |
and NSNotification
llvm-svn: 177213
|
|
|
|
| |
llvm-svn: 177172
|
|
|
|
|
|
| |
Temporarily disabled non-code-running summaries for CF*Dictionary and NSCountedSet
llvm-svn: 177171
|
|
|
|
|
|
| |
This was preventing us from providing a summary for the result of std::string.c_str() with libc++
llvm-svn: 175841
|
|
|
|
|
|
|
| |
Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp)
This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful
llvm-svn: 175787
|
|
|
|
|
|
| |
Synthetic children provider for NSSet
llvm-svn: 175468
|
|
|
|
|
|
|
|
| |
Split some NS* formatters in their own source files
Refactored a utility function for the C++ formatters to use
Fixed the skip-summary test case to be explicit about requiring libstdc++ for operation
llvm-svn: 175323
|
|
|
|
|
|
|
|
| |
The SEL data formatter was working hard to ensure that pointers-to-selectors could be formatted by the same block of code. In that effort, we were taking the address-of a SEL.
This operation fails when the SEL lives in a register, and was causing problems.
The formatter has been fixed to work correctly without assuming &selector will be a valid object.
llvm-svn: 175227
|
|
|
|
| |
llvm-svn: 174735
|
|
|
|
|
|
|
| |
Added a summary for NSMutableAttributedString
In the process, converted formatters for other NSString-based classes over to C++ code
llvm-svn: 174693
|
|
|
|
|
|
|
|
| |
Synthetic children and summary for std::vector<bool> (for both libcxx and libstdcpp).
std::vector<bool> is a special case and is custom-implemented to be a vector of bits, which means we failed to handle it with the standard std::vector<T> formatter.
This checkin provides custom formatters that work correctly
llvm-svn: 174333
|
|
Data formatters now cache themselves.
This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval.
Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization.
The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime.
Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type.
Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose.
llvm-svn: 173728
|