| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
variables in the ValueObject code:
- Report an error if the variable does not have
a valid address.
- Return the contents of the data to GetData(),
even if the value is constant.
<rdar://problem/13690855>
llvm-svn: 179876
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
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().
llvm-svn: 179437
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 179330
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ensure that option -Y also works for expression as it does for frame variable
Also, if the user passes an explicit format specifier when printing a variable, override the summary's decision to hide the value.
This is required for scenarios like this to work:
(lldb) p/x c
(Class) $0 = 0x0000000100adb7f8 NSObject
Previously this would say:
(lldb) p/x c
(Class) $0 = NSObject
ignoring the explicit format specifier
llvm-svn: 177893
|
| |
|
|
| |
llvm-svn: 177812
|
| |
|
|
| |
llvm-svn: 177810
|
| |
|
|
|
|
|
|
| |
commands of the form
frame variable -f c-string foo
where foo is an arbitrary pointer (e.g. void*) now do the right thing, i.e. they deref the pointer and try to get a c-string at the pointed address instead of dumping the pointer bytes as a string. the old behavior is used as a fallback if things don’t go well
llvm-svn: 177799
|
| |
|
|
|
|
|
|
| |
value if the variable under consideration truly is an “Objective-C thing”
This also changes the ClangASTContext to make sure that id is correctly marked as being such an ObjC thing
llvm-svn: 177203
|
| |
|
|
|
|
| |
Many "byte size" members and variables were using a mixture of uint32_t and size_t. Switching over to using uint64_t everywhere.
llvm-svn: 177091
|
| |
|
|
| |
llvm-svn: 176920
|
| |
|
|
|
|
| |
common errors
llvm-svn: 176302
|
| |
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
| |
1 - A store off the end of a buffer in ValueObject.cpp
2 - DataExtractor had cases where bad offsets could cause invalid memory to be accessed.
llvm-svn: 174757
|
| |
|
|
|
|
|
|
| |
Providing a compact display mode for "po" to use where the convenience variable name and the pointer value are both hidden.
This is for convenience when dealing with ObjC instances where the description often gets it right and the debugger-provided information is not useful to most people.
If you need either of these, "expr" will still show them.
llvm-svn: 173748
|
| |
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 173463
|
| |
|
|
|
|
|
|
|
|
| |
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.
llvm-svn: 173216
|
| |
|
|
|
|
|
|
|
| |
Providing a data formatter for libc++ std::wstring
In the process, refactoring the std::string data formatter to be written in C++ so that commonalities between the two can be exploited
Also, providing a new API on the ValueObject to navigate a hierarchy by index-path
Lastly, an appropriate test case is included
llvm-svn: 172282
|
| |
|
|
|
|
|
|
|
|
| |
Supporting a compact display syntax for ObjC pointers where 0x00.....0 is replaced by a much more legible "nil"
e.g. this would show:
(NSArray *) $2 = nil
instead of:
(NSArray *) $2 = 0x0000000000000000 <nil>
llvm-svn: 170161
|
| |
|
|
|
|
| |
Make sure that the user's choice of a format for dumping aggregate types is persisted to child members
llvm-svn: 169809
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- remove unused members
- add NO_PEDANTIC to selected Makefiles
- fix return values (removed NULL as needed)
- disable warning about four-char-constants
- remove unneeded const from operator*() declaration
- add missing lambda function return types
- fix printf() with no format string
- change sizeof to use a type name instead of variable name
- fix Linux ProcessMonitor.cpp to be 32/64 bit friendly
- disable warnings emitted by swig-generated C++ code
Patch by Matt Kopec!
llvm-svn: 169645
|
| |
|
|
|
|
|
|
| |
- as per http://llvm.org/docs/CodingStandards.html#don-t-use-default-labels-in-fully-covered-switches-over-enumerations
Patch by Matt Kopec!
llvm-svn: 169633
|
| |
|
|
|
|
| |
Fixed zero sized arrays to work correctly. This will only happen once we get a clang that emits correct debug info for zero sized arrays. For now I have marked the TestStructTypes.py as an expected failure.
llvm-svn: 169465
|
| |
|
|
|
|
|
|
|
| |
- add new header lldb-python.h to be included before other system headers
- short term fix (eventually python dependencies must be cleaned up)
Patch by Matt Kopec!
llvm-svn: 169341
|
| |
|
|
|
|
|
|
|
|
|
|
| |
The attached patch adds eValueTypeVector to lldb_private::Value. The nested struct Vector is patterned after RegisterValue::m_data.buffer. This change to Value allows ClangExpressionDeclMap::LookupDecl to return vector register data for consumption by InterpreterStackFrame::ResolveValue. Note that ResolveValue was tweaked slightly to allocate enough memory for vector registers.
An immediate result of this patch is that "expr $xmm0" generates the same results on Linux as on the Mac, which is good enough for TestRegisters.py. In addition, the log of m_memory.PrintData(data_region.m_base, data_region.m_extent) shows that the register content has been resolved successfully. On the other hand, the output is glaringly empty:
runCmd: expr $xmm0
output: (unsigned char __attribute__((ext_vector_type(16)))) $0 = {}
Expecting sub string: vector_type
Matched
llvm-svn: 167033
|
| |
|
|
|
|
|
|
|
|
|
| |
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
llvm-svn: 166857
|
| |
|
|
|
|
| |
appropriate calls in Scalar - Making sure Scalar does the right thing when casting signed values to unsigned ones.
llvm-svn: 166618
|
| |
|
|
| |
llvm-svn: 166462
|
| |
|
|
|
|
|
|
|
|
|
| |
Added a new API call to help efficiently determine if a SBValue could have children:
bool
SBValue::MightHaveChildren ();
This is inteneded to be used bui GUI programs that need to show if a SBValue needs a disclosure triangle when displaying a hierarchical type in a tree view without having to complete the type (by calling SBValue::GetNumChildren()) as completing the type is expensive.
llvm-svn: 166460
|
| |
|
|
|
|
|
|
|
|
|
| |
Given our implementation of ValueObjects we could have a scenario where a ValueObject has a dynamic type of Foo* at one point, and then its dynamic type changes to Bar*
If Bar* has synthetic children enabled, by the time we figure that out, our public API is already vending SBValues wrapping a DynamicVO, instead of a SyntheticVO and there was
no trivial way for us to change the SP inside an SBValue on the fly
This checkin reimplements SBValue in terms of a wrapper, ValueImpl, that allows this substitutions on-the-fly by overriding GetSP() to do The Right Thing (TM)
As an additional bonus, GetNonSyntheticValue() now works, and we can get rid of the ForceDisableSyntheticChildren idiom in ScriptInterpreterPython
Lastly, this checkin makes sure the synthetic VOs get the correct m_value and m_data from their parents (prevented summaries from working in some cases)
llvm-svn: 166426
|
| |
|
|
|
|
| |
our dynamic type changes
llvm-svn: 166133
|
| |
|
|
|
|
| |
Objective-C pointer changed but we still reported the one-true-definition for the previous type. This was causing issues where a variable could be reported as being of an entirely different type after an assignment
llvm-svn: 166119
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Dynamic type code must be efficient and fast. Now it is.
Added ObjC v1 support for getting the complete list of ISA values.
The main flow of the AppleObjCRuntime subclasses is now they must override "virtual bool UpdateISAToDescriptorMap_Impl();". This function will update the complete list of ISA values and create ClassDescriptorSP objects for each one. Now we have the complete list of valid ISA values which we can use for verification when doing dynamic typing.
Refactored a bunch of stuff so that the AppleObjCRuntime subclasses don't have to implement as many functions as they used to.
llvm-svn: 165730
|
| |
|
|
|
|
| |
generated by running C++ code instead of Python scripts ; Adding a bunch of value-generating APIs to our private code layer ; Providing synthetic children for NSArray
llvm-svn: 163818
|
| |
|
|
|
|
| |
Added a fix for incorrect dynamic typing. Before when asking if a C++ class could be dynamic, we would answer yes for incomplete C++ classes. This turned out to have issues where if a class was not virtual, yet had its first ivar be an instance of a virtual class, we would incorrectly say that a class was virtual and we would downcast it to be a pointer to the first ivar. We now ask the class to complete itself prior to answering the question. We need to test the effects on memory of this change prior to submission. It is the safest and best fix, but it does have a potential downside of higher memory consumption.
llvm-svn: 163014
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file".
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()
Cleaned up header includes a bit as well.
llvm-svn: 162860
|
| |
|
|
|
|
| |
commit also changes the short names for formats so that uppercase hex can be 'X', which was previously assigned to hex float. hex float now has no short name.
llvm-svn: 161606
|
| |
|
|
|
|
| |
the 'po' command
llvm-svn: 161592
|
| |
|
|
|
|
| |
for file addresses when fetching items other than the 0-th
llvm-svn: 161384
|
| |
|
|
|
|
| |
an endless recursion with synthetic children
llvm-svn: 161185
|
| |
|
|
| |
llvm-svn: 160338
|
| |
|
|
|
|
|
|
| |
Fix confusing error message about "expression did not evaluate to an address" when doing 'watchpoint set expression".
Instead of using 0 as the fail_value when invoking ValueObject::GetValueAsUnsigned(), modify the API to take an addition
bool pointer (defaults to NULL) to indicate success/failure of value conversion.
llvm-svn: 158016
|
| |
|
|
|
|
| |
determine a dynamic type for a variable of a pointer type that is not a valid generic type for dynamic pointers.
llvm-svn: 157190
|
| |
|
|
|
|
|
|
| |
DataVisualization.h / DataVisualization.cpp / ValueObject.cpp
and
FormatManager.h / FormatManager.cpp
llvm-svn: 156886
|
| |
|
|
|
|
| |
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
llvm-svn: 156422
|
| |
|
|
| |
llvm-svn: 156397
|
| |
|
|
|
|
| |
bitfields - This patch ensures that (a) freeze-drying bitfields works correctly and (b) that we actually access bitfields through IR instead of the 'frame var en lieu of expr' shortcut, for added safety in corner cases that may arise
llvm-svn: 155494
|
| |
|
|
| |
llvm-svn: 154028
|
| |
|
|
|
|
|
|
|
|
|
| |
ValueObject, and make sure that ValueObjects that
have null type names (because they have null types)
also have null qualified type names. This avoids
some potential crashes if
ValueObject::GetQualifiedTypeName tries to get the
name of their type by calling GetClangTypeImpl().
llvm-svn: 153718
|
