| 52f792329be5db8e38961350589e97e8f2823acd |
|
12-Jul-2013 |
Greg Clayton <gclayton@apple.com> |
Huge change to clean up types.
A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error.
This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@186130 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/ValueObjectDynamicValue.h
|
| 5ae1418055cbf87686d097b8addc58452e54c9c1 |
|
13-Apr-2013 |
Sean Callanan <scallanan@apple.com> |
I don't know how I managed to build with that missing
semicolon.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179442 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/ValueObjectDynamicValue.h
|
| ab8e00e51475b9148626bfdf99549b7ffc3d046d |
|
13-Apr-2013 |
Sean Callanan <scallanan@apple.com> |
Added a SetData() method to ValueObject. This
lets a ValueObject's contents be set from raw
data. This has certain limitations (notably,
registers can only be set to data that is as
large as the register) but will be useful for
the new Materializer.
I also exposed this interface through SBValue.
I have added a testcase that exercises various
special cases of SBValue::SetData().
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179437 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/ValueObjectDynamicValue.h
|
| 3b83055d13d30e8b10a15d04cd0619265e029158 |
|
12-Apr-2013 |
Enrico Granata <egranata@apple.com> |
<rdar://problem/13623698>
This patch fixes the issue that we were using the C stack as a measure of depth of ValueObject hierarchies, in the sense that we were assuming that recursive ValueObject operations would never be deeper than the stack allows.
This assumption is easy to prove wrong, however.
For instance, after ~10k runs through this loop:
struct node
{
int value;
node* child;
node (int x)
{
value = x;
child = nullptr;
}
};
int main ()
{
node root(1);
node* ptr = &root;
int j = 2;
while (1)
{
ptr->child = new node(j++);
ptr = ptr->child;
}
return 0;
}
the deepmost child object will be deeper than the stack on most architectures, and we would be unable to display it
This checkin fixes the issue by introducing a notion of root of ValueObject hierarchies.
In a couple cases, we have to use an iterative algorithm instead of going to the root because we want to allow deeper customizations (e.g. formats, dynamic values).
While the patch passes our test suite without regressions, it is a good idea to keep eyes open for any unexpected behavior (recursion can be subtle..)
Also, I am hesitant to introduce a test case since failing at this will not just be marked as an "F", but most definitely crash LLDB.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@179330 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/ValueObjectDynamicValue.h
|
| fe6dc6e241c52822710380cec0931351a1d7b2d3 |
|
14-Mar-2013 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/13421412>
Many "byte size" members and variables were using a mixture of uint32_t and size_t. Switching over to using uint64_t everywhere.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@177091 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/ValueObjectDynamicValue.h
|
| f509c5ec066599a3399fced39ea36996184939e8 |
|
29-Jan-2013 |
Enrico Granata <egranata@apple.com> |
<rdar://problem/12978143>
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.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@173728 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/ValueObjectDynamicValue.h
|
| 36da2aa6dc5ad9994b638ed09eb81c44cc05540b |
|
25-Jan-2013 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/13069948>
Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.
So I defined a new "lldb::offset_t" which should be used for all file offsets.
After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.
Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@173463 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/ValueObjectDynamicValue.h
|
| 1a469c75c0597abc2a9abdf86b624b2e71ea8650 |
|
23-Jan-2013 |
Enrico Granata <egranata@apple.com> |
<rdar://problem/12711206>
Extending ValueObjectDynamicValue so that it stores a TypeAndOrName instead of a TypeSP.
This change allows us to reflect the notion that a ValueObject can have a dynamic type for which we have no debug information.
Previously, we would coalesce that to the static type of the object, potentially losing relevant information or even getting it wrong.
This fix ensures we can correctly report the class name for Cocoa objects whose types are hidden classes that we know nothing about (e.g. __NSArrayI for immutable arrays).
As a side effect, our --show-types argument to frame variable no longer needs to append custom dynamic type information.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@173216 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/ValueObjectDynamicValue.h
|
| 89fda00f52b06b1cfe994c0320a04562b8cc1144 |
|
27-Oct-2012 |
Enrico Granata <egranata@apple.com> |
Moving ValueObjectCast over to its own .h/.cpp files instead of sharing ValueObjectDynamic.h/.cpp
Removing the IsDynamic() and GetStaticValue() calls, so that they will default to the base class behavior:
- non-dynamic
- itself as the static value
This is in contrast with the previous behavior which could be confusing and could potentially cause issues when using those objects
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@166857 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/ValueObjectDynamicValue.h
|
| 0d0f56d5b81afb0f3d2e71c53947658a4c667f35 |
|
07-Jul-2012 |
Greg Clayton <gclayton@apple.com> |
Make const result value objects able to return dynamic types.
Modified the heap.py to be able to correctly indentify the exact ivar for the "ptr_refs" command no matter how deep the ivar is in a class hierarchy. Also fixed the ability for the heap command to symbolicate the stack backtrace when MallocStackLogging is set in the environment and the "--stack" option was specified.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@159883 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/ValueObjectDynamicValue.h
|
| 651cbe2e3f6efb8bd579a5007c2d2f90f0ab7633 |
|
08-May-2012 |
Enrico Granata <egranata@apple.com> |
<rdar://problem/11239650> Fixing a bug where the SetValueFromCString() method failed to operate on dynamic values. The fix consists in making the set operation fall through to the parent. We only actually allow this if the dynamic value is at a 0-offset from the parent, or the new value is 0. Other scenarios would need agreement on the actual meaning of the set operation (do we keep offsetting? do we just assume the user knows what they are doing?) so we prevent them, and let the expression parser deal with the complexity
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@156422 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/ValueObjectDynamicValue.h
|
| dc0a38c5a727cae5362b218a3180d0f4265a619d |
|
27-Mar-2012 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/11113279>
Fixed type lookups to "do the right thing". Prior to this fix, looking up a type using "foo::bar" would result in a type list that contains all types that had "bar" as a basename unless the symbol file was able to match fully qualified names (which our DWARF parser does not).
This fix will allow type matches to be made based on the basename and then have the types that don't match filtered out. Types by name can be fully qualified, or partially qualified with the new "bool exact_match" parameter to the Module::FindTypes() method.
This fixes some issue that we discovered with dynamic type resolution as well as improves the overall type lookups in LLDB.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@153482 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/ValueObjectDynamicValue.h
|
| 931acecd4e3af534028936431dc0f75a9fd6eb02 |
|
23-Feb-2012 |
Sean Callanan <scallanan@apple.com> |
Added support for looking up the complete type for
Objective-C classes. This allows LLDB to find
ivars declared in class extensions in modules other
than where the debugger is currently stopped (we
already supported this when the debugger was
stopped in the same module as the definition).
This involved the following main changes:
- The ObjCLanguageRuntime now knows how to hunt
for the authoritative version of an Objective-C
type. It looks for the symbol indicating a
definition, and then gets the type from the
module containing that symbol.
- ValueObjects now report their type with a
potential override, and the override is set if
the type of the ValueObject is an Objective-C
class or pointer type that is defined somewhere
other than the original reported type. This
means that "frame variable" will always use the
complete type if one is available.
- The ClangASTSource now looks for the complete
type when looking for ivars. This means that
"expr" will always use the complete type if one
is available.
- I added a testcase that verifies that both
"frame variable" and "expr" work.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151214 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/ValueObjectDynamicValue.h
|
| 0a19a1b9c25117854f226256805239d95153ed2d |
|
04-Feb-2012 |
Greg Clayton <gclayton@apple.com> |
Convert all python objects in our API to use overload the __str__ method
instead of the __repr__. __repr__ is a function that should return an
expression that can be used to recreate an python object and we were using
it to just return a human readable string.
Fixed a crasher when using the new implementation of SBValue::Cast(SBType).
Thread hardened lldb::SBValue and lldb::SBWatchpoint and did other general
improvements to the API.
Fixed a crasher in lldb::SBValue::GetChildMemberWithName() where we didn't
correctly handle not having a target.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@149743 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/ValueObjectDynamicValue.h
|
| 4e6640ee7975a9b9b0854aaa1f4d2d0f08702110 |
|
03-Feb-2012 |
Greg Clayton <gclayton@apple.com> |
Fixed casting in the lldb::SBValue::Cast(SBType) function.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@149673 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/ValueObjectDynamicValue.h
|
| 1b42575189379cb0c1441f74a48127e9ab7335e3 |
|
08-Dec-2011 |
Jim Ingham <jingham@apple.com> |
Add SBValue::GetDynamicValue and SBValue::GetStaticValue API's.
<rdar://problem/10545069>
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@146173 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/ValueObjectDynamicValue.h
|
| 10de7d1db3ec782ea2ccda1f39c0a40b9c301594 |
|
04-May-2011 |
Jim Ingham <jingham@apple.com> |
Change "frame var" over to using OptionGroups (and thus the OptionGroupVariableObjectDisplay).
Change the boolean "use_dynamic" over to a tri-state, no-dynamic, dynamic-w/o running target,
and dynamic with running target.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@130832 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/ValueObjectDynamicValue.h
|
| 47da810225d8674eb9158bcf5f1f5b847cbaeedf |
|
23-Apr-2011 |
Jim Ingham <jingham@apple.com> |
Fix up how the ValueObjects manage their life cycle so that you can hand out a shared
pointer to a ValueObject or any of its dependent ValueObjects, and the whole cluster will
stay around as long as that shared pointer stays around.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@130035 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/ValueObjectDynamicValue.h
|
| e41494a9092e15192012a5e0a8a1ffd66c70b8bb |
|
16-Apr-2011 |
Jim Ingham <jingham@apple.com> |
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the
expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will
have to be changed to also query for the dynamic types & offsets as it is looking up variables.
The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var
command to get the dynamic or static value of the variables you are printing.
There's also a general setting:
target.prefer-dynamic-value (boolean) = 'true'
which is consulted if you call "frame var" without supplying a value for the -d option.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@129623 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/include/lldb/Core/ValueObjectDynamicValue.h
|