| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 265979
|
|
|
|
| |
llvm-svn: 265978
|
|
|
|
| |
llvm-svn: 265865
|
|
|
|
|
|
| |
Fixes <rdar://problem/25629755>
llvm-svn: 265849
|
|
|
|
| |
llvm-svn: 265181
|
|
|
|
|
|
|
|
|
|
|
|
| |
others, BOOL == signed char.
This can cause differences in which bit patterns end up meaning YES or NO. In general, however, 0 == NO and 1 == YES.
To keep it simple, LLDB will now show "YES" and "NO" only for 1 and 0 respectively, and format other values as the plain numeric value instead.
Fixes rdar://24809994
llvm-svn: 263604
|
|
|
|
|
|
| |
type NSError**. Fixes rdar://25060684
llvm-svn: 263603
|
|
|
|
| |
llvm-svn: 262322
|
|
|
|
|
|
| |
up empty
llvm-svn: 262260
|
|
|
|
|
|
|
|
| |
containers
Fixes rdar://23715118
llvm-svn: 262254
|
|
|
|
|
|
| |
other minor fixes.
llvm-svn: 262246
|
|
|
|
| |
llvm-svn: 262214
|
|
|
|
|
|
|
|
|
| |
The purpose of these plugins is to make LLDB capable of debugging java
code JIT-ed by the android runtime.
Differential revision: http://reviews.llvm.org/D17616
llvm-svn: 262015
|
|
|
|
|
|
| |
the right thing and break.
llvm-svn: 261950
|
|
|
|
| |
llvm-svn: 260761
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
contain logic to inspect the objects without running code.
However, they also contain fallback logic that - in cases where LLDB can't recognize the specific subclass - actually does run code in order to inspect those objects.
The argument for this logic was that these data types are critical enough that the risk of getting it wrong is outweighed by the advantage of always providing accurate child information.
Practical experience however shows that "po" - a code running data-inspection command - is quite frequently used, and not considered burdensome by users.
As such, this makes the code-running fallback in the data formatters a risk that carries very little actual reward. Also, unlike the time this code was originally written, we now have accurate class information for Objective-C, and thus we are less likely to improperly identify classes.
This commit removes support for the code-running fallback, and aligns the data formatters for NSArray, NSDictionary and NSSet to the general no-code-running behavior of other data formatters.
While it is possible for us to add support for some subclasses that are now no longer covered by static inspection alone, this is beyond the scope of this commit.
llvm-svn: 260664
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D16662
llvm-svn: 259098
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
names that this formatter uses for fields; use the {} syntax to make it so that a failure to parse the summary doesn't cause the entire printout to fail
llvm-svn: 256042
|
|
|
|
| |
llvm-svn: 254787
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
every loop iteration
This saves about 5 seconds on a 1500 elements list from my local estimates
llvm-svn: 254757
|
|
|
|
|
|
|
|
|
|
| |
are "nil" (not pointing to anything) or uninitialized (never made to point at anything)
This latter determination may or may not be possible on a per-language basis; and neither is mandatory to implement for any language
Use this knowledge in the ValueObjectPrinter to generalize the notion of IsObjCNil() and the respective printout
llvm-svn: 252663
|
|
|
|
|
|
|
|
|
|
|
| |
Fixed Clang-tidy warnings:
* modernize-use-override;
* modernize-use-nullptr;
* modernize-use-default;
* readability-simplify-boolean-expr.
llvm-svn: 252374
|
|
|
|
| |
llvm-svn: 252269
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D13878
llvm-svn: 252109
|
|
|
|
|
|
| |
producing any evidence thereof
llvm-svn: 252018
|
|
|
|
|
|
| |
don't really want
llvm-svn: 251670
|
|
|
|
| |
llvm-svn: 251663
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
than a
StackFrame * (StackFrame is an ExecutionContextScope.) That allows you to call an
expression on a particular Thread, but not using the context of any particular frame.
That in turn is useful for injecting utility functions that don't actually depend on
locals/self/etc of the current frame.
I also had to include StackFrame.h in a couple of places so the compiler knew
how to downcast StackFrame to ExecutionContextScope.
<rdar://problem/22852953>
llvm-svn: 251564
|
|
|
|
| |
llvm-svn: 251403
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
* 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
|
|
|
|
|
|
| |
See http://reviews.llvm.org/D13964 for details.
llvm-svn: 250965
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 250798
|
|
|
|
|
|
|
|
| |
other minor fixes.
Differential Revision: http://reviews.llvm.org/D13876
llvm-svn: 250789
|
|
|
|
| |
llvm-svn: 250341
|
|
|
|
|
|
|
|
|
| |
Introduce the notion of Language-based formatter prefix/suffix
This is meant for languages that share certain data types but present them in syntatically different ways, such that LLDB can now have language-based awareness of which of the syntax variations it has to present to the user when formatting those values
This is goodness for new languages and interoperability, but is NFC for existing languages. As such, existing tests cover this
llvm-svn: 249587
|
|
|
|
|
|
| |
single character; and also introduce a comparable suffix mechanism
llvm-svn: 249506
|
|
|
|
|
|
|
|
| |
argument, and use it when crafting summaries by running selectors
This is the first in a series of commits that are meant to teach LLDB how to properly handle multi-language formatting of values
llvm-svn: 249503
|
|
|
|
| |
llvm-svn: 249189
|
|
|
|
|
|
|
|
| |
to other types beyond the well-known ones
This is meant to support languages that can do some sort of bridging from<-->to these ObjC types via types that statically vend themselves as Cocoa types, but dynamically have an implementation that does not match any of our well-known types, but where an introspecting formatter can be vended by the bridged language
llvm-svn: 249185
|
|
|
|
|
|
|
| |
Also made it not store nullptrs in its TypeSystemMap, so it will retry to make
the AST context if it errored out last time.
llvm-svn: 249167
|
|
|
|
| |
llvm-svn: 249117
|
|
|
|
| |
llvm-svn: 249055
|
|
|
|
|
|
|
|
|
|
| |
information by name in a language-specific way.
Currently, it only supports Objective-C - C++ types can be looked up through debug info via 'image lookup -t', whereas ObjC types via this command are looked up by runtime introspection
This behavior is in line with type lookup's behavior in Xcode 7, but I am definitely open to feedback as to what makes the most sense here
llvm-svn: 249047
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13102
llvm-svn: 248461
|