The ClangExpressionVariable::CreateVariableInList functions looked cute, but
caused more confusion than they solved. I removed them, and instead made sure
that there are adequate facilities for easily adding newly-constructed
ExpressionVariables to lists.
I also made some of the constructors that are common be generic, so that it's
possible to construct expression variables from generic places (like the ABI and
ValueObject) without having to know the specifics about the class.
llvm-svn: 249095
Also added some target-level search functions so that persistent variables and
symbols can be searched for without hand-iterating across the map of
TypeSystems.
llvm-svn: 249027
the corresponding TypeSystem. This makes sense because what kind of data there
is -- and how it can be looked up -- depends on the language.
Functionality that is common to all type systems is factored out into
PersistentExpressionState.
llvm-svn: 248934
There are still a bunch of dependencies on the plug-in, but this helps to
identify them.
There are also a few more bits we need to move (and abstract, for example the
ClangPersistentVariables).
llvm-svn: 248612
Summary:
With the recent changes to separate clang from the core structures
of LLDB, many inclusions of clang headers can be removed.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D12954
llvm-svn: 248004
stores information about a variable that different parts of LLDB use, from the
compiler-specific portion that only the expression parser cares about.
http://reviews.llvm.org/D12602
llvm-svn: 246871
This is still something I need to fix, but at least it's not so ugly, and it's
consistent with the other code that does that so we will catch it when we purge
all such code.
llvm-svn: 246738
Clang-specific part, create the ExpressionVariable source/header file and
move ClangExpressionVariable into the Clang expression parser plugin.
It is expected that there are some ugly #include paths... these will be resolved
by either (1) making that code use generic expression variables (once they're
separated appropriately) or (2) moving that code into a plug-in, often
the expression parser plug-in.
llvm-svn: 246737
Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files.
Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types.
Bulk renames for things that used to return a ClangASTType which is now CompilerType:
"Type::GetClangFullType()" to "Type::GetFullCompilerType()"
"Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()"
"Type::GetClangForwardType()" to "Type::GetForwardCompilerType()"
"Value::GetClangType()" to "Value::GetCompilerType()"
"Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)"
"ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()"
many more renames that are similar.
llvm-svn: 245905
Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp
Reviewers: tberghammer, ovyalov, clayborg, labath
Subscribers: lldb-commits, nitesh.jain, jaydeep
Differential: http://reviews.llvm.org/D12100
llvm-svn: 245547
Eliminated ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and use llvm::APInt and llvm::APFloat for all integer and floating point types. Also used Scalar in RegisterValue.cpp
Reviewers: jaydeep, clayborg, jasonmolenda, ovyalov, emaste
Subscribers: tberghammer, ovyalov, emaste, mohit.bhakkad, nitesh.jain, bhushan
Differential: http://reviews.llvm.org/D10919
llvm-svn: 245216
This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc).
llvm-svn: 244689
This is the work done by Ryan Brown from http://reviews.llvm.org/D8712 that makes a TypeSystem class and abstracts types to be able to use a type system.
All tests pass on MacOSX and passed on linux the last time this was submitted.
llvm-svn: 244679
This change :
- Fixes offsets of all register sets for Mips.
- Adds MSA register set and FRE=1 mode support for FP register set.
- Separates lldb register numbers and register infos of freebsd/mips64 from linux/mips64.
- Re-orders the register numbers of all kinds for mips to be consistent with freebsd order of register numbers.
- Eliminates ENABLE_128_BIT_SUPPORT and union ValueData from Scalar.cpp and uses llvm::APInt and llvm::APFloat for all integer and floating point types.
Reviewers : emaste, jaydeep, clayborg
Subscribers : emaste, mohit.bhakkad, nitesh.jain, bhushan
Differential : http://reviews.llvm.org/D10919
llvm-svn: 244308
This was of course overridable by using DumpValueObjectOptions, but the default should be saner and the previous behavior made for a few fun investigations....
rdar://problem/21065149
llvm-svn: 238961
Since interaction with the python interpreter is moving towards
being more isolated, we won't be able to include this header from
normal files anymore, all includes of it should be localized to
the python library which will live under source/bindings/API/Python
after a future patch.
None of the files that were including this header actually depended
on it anyway, so it was just a dead include in every single instance.
llvm-svn: 238581
And they also do not have a thread/frame attached to them
That makes dynamic and synthetic values attached to them impossible to update - which, among other things, makes it impossible to properly display persistent variables of types that could have such dynamic/persistent values
Fix this by making it so that a ValueObject can control its constantness (hint: dynamic and synthetic values cannot be constant) and whether it wants to let itself be updated when an invalid thread is around
llvm-svn: 237504
Summary:
After r236447, ValueObject::GetAddressOf returns LLDB_INVALID_ADDRESS
when the value type is eValueHostAddress. For such a case, clients of
GetAddressOf should get the address from the scalar part of the value
instead of using the value returned by GetAddressOf directly.
This change also makes ValueObject::GetAddressOf set the address type to
eAddressTypeHost for values of eValueHostAddress so that clients can
recognize that they need to fetch the address from the scalar part
of the value.
Test Plan: ninja check-lldb on linux
Reviewers: clayborg, ovyalov
Reviewed By: ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9490
llvm-svn: 236473
Summary:
This fixes TestRegisterVariables for clang and hence it is enabled in this commit.
Test Plan: dotest.py -C clang -p TestRegisterVariables
Reviewers: clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9421
llvm-svn: 236447
Summary:
The code for GetSyntheticArrayMemberFromPointer and
GetSyntheticArrayMemberFromArray was identical, so just collapse the
the methods into one.
Reviewers: granata.enrico, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7911
llvm-svn: 230708
There was a test in the test suite that was triggering the backtrace logging output that requested that the client pass an execution context. Sometimes we need the process for Objective C types because our static notion of the type might not align with the reality when being run in a live runtime.
Switched from an "ExecutionContext *" to an "ExecutionContextScope *" for greater ease of use.
llvm-svn: 228892
A runtime support value is a ValueObject whose only purpose is to support some language runtime's operation, but it does not directly provide any user-visible benefit
As such, unless the user is working on the runtime support, it is mostly safe for them not to see such a value when debugging
It is a language runtime's job to check whether a ValueObject is a support value, and that - in conjunction with a target setting - is used by frame variable and target variable
SBFrame::GetVariables gets a new overload with yet another flag to dictate whether to return those support values to the caller - that which defaults to the setting's value
rdar://problem/15539930
llvm-svn: 228791
And since enough of these are doing the right thing, add a test case to verify we are doing the right thing with freeze drying ObjC object types
Fixes rdar://18092770
llvm-svn: 227282
This is necessary because the byte size of an ObjC class type is not reliably statically knowable (e.g. because superclasses sit deep in frameworks that we have no debug info for)
The lack of reliable size info is a problem when trying to freeze-dry an ObjC instance (not the pointer, the pointee)
This commit lays the foundation for having language runtimes help in figuring out byte sizes, and having ClangASTType ask for runtime help
No feature change as no runtime actually implements the logic, and nowhere is an ExecutionContext passed in yet
llvm-svn: 227274
Most of the time, we can use context information just fine to choose a language (i.e. the language of the frame that the root object was defined in, if any); but in some cases, synthetic children may be fabricated as root frame-less entities, and then we wouldn't know any better
This patch allows (internal) synthetic child providers to set a display language on the children they generate, should they so choose
llvm-svn: 226634
It also comes with a (rudimentary) test case that gets itself in a failed update scenario, and checks that we don't crash
This is the easiest case I could think of that forces the failed update case Zachary was seeing
llvm-svn: 225463
Function pointers had a summary generated for them bypassing formatters, directly as part of the ValueObject subsystem
This patch transitions that code into a hardcoded summary
llvm-svn: 223906
Because of the way they are created, synthetic children cannot (in general) have a sane expression path
A solution to this would be letting the parent front-end generate expression paths for its children
Doing so requires a significant amount of refactoring, and might not always lead to better results (esp. w.r.t. C++ templates)
This commit takes a simpler approach:
- if a synthetic child is of pointer type and it's a target pointer, then emit *((T)value)
- if a synthetic child is a non-pointer, but its location is in the target, then emit *((T*)loadAddr)
- if a synthetic child has a value, emit ((T)value)
- else, don't emit anything
Fixes rdar://18442386
llvm-svn: 223836
track of the checksum of the object so we can
track if it is modified. This fixes a testcase
(test/expression_command/issue_11588) on OS X.
Patch by Enrico Granata.
llvm-svn: 223830
- adds a new flag to mark ValueObjects as "synthetic children generated"
- vends new Create functions as part of the SyntheticChildrenFrontEnd that set the flag automatically
- moves synthetic child providers over to using these new functions
No visible feature change, but preparatory work for feature change
llvm-svn: 223819
Such a persisted version is equivalent to evaluating the value via the expression evaluator, and holding on to the $n result of the expression, except this API can be used on SBValues that do not obviously come from an expression (e.g. are the result of a memory lookup)
Expose this via SBValue::Persist() in our public API layer, and ValueObject::Persist() in the lldb_private layer
Includes testcase
Fixes rdar://19136664
llvm-svn: 223711
Sean Callanan