summaryrefslogtreecommitdiffstats
path: root/lldb/source/Core/ValueObject.cpp
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Add the ability for an SBValue to create a persisted version of itself.Enrico Granata2014-12-081-0/+26
| | | | | | | | | | | | 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
* Shuffle APIs around a little bit, so that if you pass custom summary ↵Enrico Granata2014-11-181-7/+10
| | | | | | options, we don't end up caching the summary hence obtained. You may want to obtain an uncapped summary, but this should not be reflected in the summary we cache. The drawback is that we don't cache as aggressively as we could, but at least you get to have different summaries with different options without having to reset formatters or the SBValue at each step llvm-svn: 222280
* This is a large, but clearical, commit that enables the C++ formatters to ↵Enrico Granata2014-11-061-1/+1
| | | | | | take on the additional TypeSummaryOptions argument. It is still not used for anything, but it is now there. Adding support for this extra argument to Python formatters will follow suit llvm-svn: 221486
* Introduce the notion of "type summary options" as flags that can be passed ↵Enrico Granata2014-11-061-1/+40
| | | | | | | | | | | | | down to individual summary formatters to alter their behavior in a formatter-dependent way Two flags are introduced: - preferred display language (as in, ObjC vs. C++) - summary capping (as in, should a limit be put to the amount of data retrieved) The meaning - if any - of these options is for individual formatters to establish The topic of a subsequent commit will be to actually wire these through to individual data formatters llvm-svn: 221482
* Add a setting escape-non-printables that drives whether the StringPrinter ↵Enrico Granata2014-11-051-2/+1
| | | | | | | | | | | should or should not escape sequences such as \t, \n, .. and generally any non-printing character The recent StringPrinter changes made this behavior the default, and the setting defaults to yes If you want to change this behavior and see non-printables unescaped (e.g. "a\tb" as "a b"), set it to false Fixes rdar://12969594 llvm-svn: 221399
* Also port the C string reading code in ValueObject over to using ↵Enrico Granata2014-10-301-32/+36
| | | | | | StringPrinter API llvm-svn: 220917
* Expose the type-info flags at the public API layer. These flags provide much ↵Enrico Granata2014-10-211-48/+48
| | | | | | more informational content to consumers of the LLDB API than the existing TypeClass. Part of the fix for rdar://18517593 llvm-svn: 220322
* Remove default case from a fully covered switch.Eric Christopher2014-10-111-1/+0
| | | | llvm-svn: 219548
* Add an API on ValueObject to retrieve the desired dynamic/synthetic ↵Enrico Granata2014-10-091-0/+50
| | | | | | combination all at once, if available, working somewhat hard to avoid returning an invalid ValueObject in the process llvm-svn: 219423
* Extend synthetic children to produce synthetic values (as in, those that ↵Enrico Granata2014-10-081-5/+11
| | | | | | | | | | | | | | | | | GetValueAsUnsigned(), GetValueAsCString() would return) The way to do this is to write a synthetic child provider for your type, and have it vend the (optional) get_value function. If get_value is defined, and it returns a valid SBValue, that SBValue's value (as in lldb_private::Value) will be used as the synthetic ValueObject's Value The rationale for doing things this way is twofold: - there are many possible ways to define a "value" (SBData, a Python number, ...) but SBValue seems general enough as a thing that stores a "value", so we just trade values that way and that keeps our currency trivial - we could introduce a new level of layering (ValueObjectSyntheticValue), a new kind of formatter (synthetic value producer), but that would complicate the model (can I have a dynamic with no synthetic children but synthetic value? synthetic value with synthetic children but no dynamic?), and I really couldn't see much benefit to be reaped from this added complexity in the matrix On the other hand, just defining a synthetic child provider with a get_value but returning no actual children is easy enough that it's not a significant road-block to adoption of this feature Comes with a test case llvm-svn: 219330
* Start plumbing the type validator logic through to the ValueObjects; allow a ↵Enrico Granata2014-09-051-2/+25
| | | | | | ValueObject to have a validator, to update it from the FormatManager, and to retrieve (and cache) the result of the validation llvm-svn: 217282
* It was pointed out to me that an offset of 0 makes sense for ObjC, but not ↵Enrico Granata2014-08-261-2/+1
| | | | | | always for C++, and this API claims to be general enough that it should not drop C++ usability on the floor for no good reason. Fix it with an explicit offset argument llvm-svn: 216487
* Add an API on ValueObject to generate a 'synthetic child' of base class ↵Enrico Granata2014-08-261-0/+42
| | | | | | type. Note that in this commit, the term synthetic child is not meant to refer to data formatters, but to the programmatically-generated children stored inside a ValueObject itself llvm-svn: 216483
* Add an accessor to ValueObject that determines if the object represents a ↵Enrico Granata2014-08-191-0/+20
| | | | | | base class, and also returns the depth of base-class-ness. For instance if one has class C : public B {} class B : public A {}, the value for A nested in B nested in C would be a base class of depth 2 llvm-svn: 216032
OpenPOWER on IntegriCloud