summaryrefslogtreecommitdiffstats
path: root/lldb/source/Core/ValueObject.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Add an argument to ValueObject::GetSyntheticBase that allows for name ↵Enrico Granata2016-05-021-4/+10
| | | | | | customization on the generated value llvm-svn: 268274
* Handle bit fields on big-endian systems correctlyUlrich Weigand2016-04-141-2/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, the DataExtractor::GetMaxU64Bitfield and GetMaxS64Bitfield routines assume the incoming "bitfield_bit_offset" parameter uses little-endian bit numbering, i.e. a bitfield_bit_offset 0 refers to a bitfield whose least-significant bit coincides with the least- significant bit of the surrounding integer. On many big-endian systems, however, the big-endian bit numbering is used for bit fields. Here, a bitfield_bit_offset 0 refers to a bitfield whose most-significant bit conincides with the most- significant bit of the surrounding integer. Now, in principle LLDB could arbitrarily choose which semantics of bitfield_bit_offset to use. However, there are two problems with the current approach: - When parsing DWARF, LLDB decodes bit offsets in little-endian bit numbering on LE systems, but in big-endian bit numbering on BE systems. Passing those offsets later on into the DataExtractor routines gives incorrect results on BE. - In the interim, LLDB's type layer combines byte and bit offsets into a single number. I.e. instead of recording bitfields by specifying the byte offset and byte size of the surrounding integer *plus* the bit offset of the bit field within that field, it simply records a single bit offset number. Now, note that converting from byte offset + bit offset to a single offset value and back is well-defined if we either use little-endian byte order *and* little-endian bit numbering, or use big-endian byte order *and* big-endian bit numbering. Any other combination will yield incorrect results. Therefore, the simplest approach would seem to be to always use the bit numbering that matches the system byte order. This makes storing a single bit offset valid, and makes the existing DWARF code correct. The only place to fix is to teach DataExtractor to use big-endian bit numbering on big endian systems. However, there is only additional caveat: we also get bit offsets from LLDB synthetic bitfields. While the exact semantics of those doesn't seem to be well-defined, from test cases it appears that the intent was for the user-provided synthetic bitfield offset to always use little-endian bit numbering. Therefore, on a big-endian system we now have to convert those to big-endian bit numbering to remain consistent. Differential Revision: http://reviews.llvm.org/D18982 llvm-svn: 266312
* Fixed ValueObject::GetExpressionPath() for paths including anonymous ↵Marianne Mailhot-Sarrasin2016-03-101-1/+1
| | | | | | | | | | struct/union When the parent of an expression is anonymous, skip adding '.' or '->' before the expression name. Differential Revision: http://reviews.llvm.org/D18005 llvm-svn: 263166
* Add an LLDB data formatter for single-element NSArray and NSDictionary Cocoa ↵Enrico Granata2016-02-291-4/+10
| | | | | | | | containers Fixes rdar://23715118 llvm-svn: 262254
* Fix all of the unannotated switch cases to annotate the fall through or do ↵Greg Clayton2016-02-261-0/+1
| | | | | | the right thing and break. llvm-svn: 261950
* No need for a custom function here; just use what C providesEnrico Granata2015-12-221-29/+1
| | | | llvm-svn: 256223
* Reduce code duplicationEnrico Granata2015-12-211-64/+16
| | | | llvm-svn: 256212
* Inspect DW_AT_const_value global static const variablesEwan Crawford2015-12-171-0/+1
| | | | | | | | | | | | 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
* Introduce a way for Languages to specify whether values of "reference types" ↵Enrico Granata2015-11-101-8/+16
| | | | | | | | | | are "nil" (not pointing to anything) or uninitialized (never made to point at anything) 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
* Add a way for source languages to "mark" ValueObjects with language-specific ↵Enrico Granata2015-11-091-7/+30
| | | | | | | | | | flags 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
* [Core] Avoid default in switch() that covers all the cases.Davide Italiano2015-11-041-1/+0
| | | | | | Unbreak the build for FreeBSD + -Werror. llvm-svn: 252079
* Fix an issue where LLDB would truncate summaries for string types without ↵Enrico Granata2015-11-041-11/+13
| | | | | | producing any evidence thereof llvm-svn: 252018
* Do not try to copy host memory from address 0Enrico Granata2015-11-031-1/+1
| | | | llvm-svn: 251889
* Change ValueObject::IsLogicalTrue so that it starts by asking the applicable ↵Enrico Granata2015-11-021-0/+15
| | | | | | Language plugin before using the C-style rule llvm-svn: 251838
* Abstract the notion of the truth value of an expression result, for useJim Ingham2015-10-311-0/+20
| | | | | | in breakpoint conditions. llvm-svn: 251727
* [SBValue] Add a method GetNumChildren(uint32_t max)Siva Chandra2015-10-211-1/+13
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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
OpenPOWER on IntegriCloud