summaryrefslogtreecommitdiffstats
path: root/lldb/source/Core/ValueObject.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Route the preferred-display-language mechanism to the ValueObjectPrinter and ↵Enrico Granata2015-10-071-0/+7
| | | | | | actually fill in a few gaps for dynamic and synthetic values to be able to adopt this in useful ways llvm-svn: 249507
* Introduce a variant of GetSummaryAsCString() that takes a LanguageType ↵Enrico Granata2015-10-071-11/+19
| | | | | | | | 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
* Create a logging category that is specific to data formatters activityEnrico Granata2015-10-061-1/+1
| | | | llvm-svn: 249433
* Eliminated redundant "constructors" for ClangExpressionVariable. ↵Sean Callanan2015-10-011-7/+5
| | | | | | | | | | | | | 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
* Made Target hold a map of languages to TypeSystems, and added some accessors.Sean Callanan2015-10-011-1/+1
| | | | | | | | 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
* Use the preferred display language when making a persistent variable from aSean Callanan2015-10-011-1/+1
| | | | | | ValueObject. llvm-svn: 248971
* Now persistent expression data no longer lives with the Target, but rather withSean Callanan2015-09-301-2/+7
| | | | | | | | | | 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
* Moved more Clang-specific parts of the expression parser into the Clang plugin.Sean Callanan2015-09-251-1/+1
| | | | | | | | | 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
* Rename clang_type -> compiler_type for variables.Bruce Mitchener2015-09-241-75/+75
| | | | | | | | | | Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13102 llvm-svn: 248461
* Rename GetChildClangTypeAtIndex to GetChildCompilerTypeAtIndexBruce Mitchener2015-09-211-33/+33
| | | | | | | | | | Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13020 llvm-svn: 248175
* Reduce inclusion of clang headers.Bruce Mitchener2015-09-181-1/+0
| | | | | | | | | | | | | | 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
* Introduce the notion of an escape helper. Different languages have different ↵Enrico Granata2015-09-091-2/+2
| | | | | | | | notion of what to print in a string and how to escape non-printable things. The escape helper is where this notion is provided to LLDB This is NFC, other than a code re-org llvm-svn: 247200
* Preparatory work for letting language plugins help the StringPrinter with ↵Enrico Granata2015-09-091-1/+1
| | | | | | formatting special characters llvm-svn: 247189
* This patch separates the generic portion of ClangExpressionVariable, whichSean Callanan2015-09-041-1/+1
| | | | | | | | | 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
* Jim told me about a cleaner way to include headers from plug-ins.Sean Callanan2015-09-031-1/+1
| | | | | | | | 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
* In preparation for factoring persistent variables into a generic part and aSean Callanan2015-09-031-1/+1
| | | | | | | | | | | | 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
* Final bit of type system cleanup that abstracts declaration contexts into ↵Greg Clayton2015-08-241-35/+35
| | | | | | | | | | | | | | | | | | | | lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. 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
* [LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValueSagar Thakur2015-08-201-1/+1
| | | | | | | | | 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
* Revert "[LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValue"Pavel Labath2015-08-171-1/+1
| | | | | | Reverting as this commit causes an infinite loop. llvm-svn: 245222
* [LLDB] Use llvm::APInt and llvm::APFloat in Scalar and RegisterValueSagar Thakur2015-08-171-1/+1
| | | | | | | | | 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
* ClangASTType is now CompilerType.Greg Clayton2015-08-111-33/+33
| | | | | | This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc). llvm-svn: 244689
* First step in getting LLDB ready to support multiple different type systems.Greg Clayton2015-08-111-3/+3
| | | | | | | | 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
* Revert r244308 since it's introducing test regressions on Linux:Oleksiy Vyalov2015-08-101-1/+1
| | | | | | | | - TestLldbGdbServer.py both clang & gcc, i386 and x86_64 - TestConstVariables.py gcc, i386 and x86_64 - 112 failures clang, i386 llvm-svn: 244514
* [LLDB][MIPS] Fix offsets of all register sets and add MSA regset and FRE=1 ↵Sagar Thakur2015-08-071-1/+1
| | | | | | | | | | | | | | | | | | mode support 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
* Allow ValueObject::Dereference to dereference references.Chaoren Lin2015-07-311-6/+6
| | | | | | | | | | Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11667 llvm-svn: 243716
* Revert "Introduce a TypeSystem interface to support adding non-clang languages."Pavel Labath2015-06-081-3/+3
| | | | | | This seems to break expression evaluation on the linux build. llvm-svn: 239366
* Introduce a TypeSystem interface to support adding non-clang languages.Pavel Labath2015-06-081-3/+3
| | | | | | | | | | | | | Reviewers: clayborg Reviewed By: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D8712 Original Author: Ryan Brown <ribrdb@google.com> llvm-svn: 239360
* Fix a bug where trying to Dump() a ValueObject would use the ↵Enrico Granata2015-06-031-2/+2
| | | | | | | | | | static/non-synthetic version of the value even if the ValueObject one actually called Dump() on turned out to be dynamic and/or synthetic 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
* Don't #include "lldb-python.h" from anywhere.Zachary Turner2015-05-291-2/+0
| | | | | | | | | | | | | 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
* Remove unused #includes of ScriptInterpreterPython.hZachary Turner2015-05-281-1/+0
| | | | llvm-svn: 238470
* Constant result ValueObjects are - well - constantEnrico Granata2015-05-161-19/+21
| | | | | | | | | | 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
* [ValueObject::GetPointeeData] Get addr from value for eValueHostAddress values.Siva Chandra2015-05-051-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* [ValueObject] Do not return address of eValueTypeHostAddress values.Siva Chandra2015-05-041-3/+5
| | | | | | | | | | | | | | | | | | 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
* This fixes the build I previously broke - and actually makes the test case ↵Enrico Granata2015-03-121-24/+74
| | | | | | work just like I promised llvm-svn: 232115
* Remove duplicated code for synthetic array members.Bruce Mitchener2015-02-261-52/+6
| | | | | | | | | | | | | | | | | 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
* Make a more complete fix for always supplying an execution context when ↵Greg Clayton2015-02-121-4/+4
| | | | | | | | | | getting byte sizes from types. 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
* Introduce the notion of "runtime support values"Enrico Granata2015-02-111-0/+15
| | | | | | | | | | | | 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
* Move several GetByteSize() calls over to the brave new world of taking an ↵Enrico Granata2015-01-281-4/+10
| | | | | | | | | | ExecutionContext* 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
* Preparatory infrastructural work to support dynamically determining sizes of ↵Enrico Granata2015-01-281-4/+4
| | | | | | | | | | | | ObjC types via the runtime 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
* Fix indentation in ValueObject.cpp (test commit)Tamas Berghammer2015-01-231-2/+2
| | | | llvm-svn: 226906
* Add an API to ValueObject that iterates over the entire parent chain via a ↵Enrico Granata2015-01-221-8/+14
| | | | | | callback, and rewrite GetRoot() in terms of this general iteration API. NFC llvm-svn: 226771
* Allow individual ValueObjects to pick their preferred display languageEnrico Granata2015-01-211-12/+23
| | | | | | | | 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
* This patch fixes my think-o in ValueObject::UpdateValueIfNeeded() about the ↵Enrico Granata2015-01-081-2/+2
| | | | | | | | | right thing to assert() 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
* Fix a problem where a ValueObject could fail to update itself, but since it ↵Enrico Granata2015-01-081-1/+1
| | | | | | was previously valid, we'd have an old checksum to compare aginst no new checksum (because failure to update), and assert() and die. Fix the problem by only caring about this assertion logic if updates succeed llvm-svn: 225418
* Cleanup some redundant codeEnrico Granata2014-12-201-3/+1
| | | | llvm-svn: 224659
* Provide CreateValueFromData,Expression at the SBTarget level as well as the ↵Enrico Granata2014-12-171-2/+13
| | | | | | SBValue level; and also make all the implenentations agree on using the matching ValueObject::Create instead of doing code copypastas llvm-svn: 224460
* Remove the last vestige of the world before data formatters :-)Enrico Granata2014-12-101-59/+4
| | | | | | | | 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
* Extend ValueObject::GetExpressionPath() to do something reasonable for ↵Enrico Granata2014-12-091-0/+40
| | | | | | | | | | | | | | | | | | | synthetic children 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
* Fixed ValueObject::UpdateValueIfNeeded to keepSean Callanan2014-12-091-10/+47
| | | | | | | | | | 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
* This patch does a few things:Enrico Granata2014-12-091-2/+16
| | | | | | | | | | - 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
OpenPOWER on IntegriCloud