This patch adds support for printing global static const variables which are given a DW_AT_const_value DWARF tag by clang.
Fix for bug https://llvm.org/bugs/show_bug.cgi?id=25653
Reviewers: clayborg, tberghammer
Subscribers: emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D15576
llvm-svn: 255887
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
In this way, when a language needs to tell itself things that are not bound to a type but to a value (imagine a base-class relation, this is not about the type, but about the ValueObject), it can do so in a clean and general fashion
The interpretation of the values of the flags is, of course, up to the language that owns the value (the value object's runtime language, that is)
llvm-svn: 252503
Summary:
Along with this, support for an optional argument to the "num_children"
method of a Python synthetic child provider has also been added. These have
been added with the following use case in mind:
Synthetic child providers currently have a method "has_children" and
"num_children". While the former is good enough to know if there are
children, it does not give any insight into how many children there are.
Though the latter serves this purpose, calculating the number for children
of a data structure could be an O(N) operation if the data structure has N
children. The new method added in this change provide a middle ground.
One can call GetNumChildren(K) to know if a child exists at an index K
which can be as large as the callers tolerance can be. If the caller wants
to know about children beyond K, it can make an other call with 2K. If the
synthetic child provider maintains state about it counting till K
previosly, then the next call is only an O(K) operation. Infact, all
calls made progressively with steps of K will be O(K) operations.
Reviewers: vharron, clayborg, granata.enrico
Subscribers: labath, lldb-commits
Differential Revision: http://reviews.llvm.org/D13778
llvm-svn: 250930
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
Enrico Granata