summaryrefslogtreecommitdiffstats
path: root/lldb/source/Core/ValueObject.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Re-add the StringRef interface changes for Variable.Zachary Turner2016-11-181-13/+13
| | | | | | | | This concludes the changes I originally tried to make and then had to back out. This way if anything is still broken, it should be easier to bisect it back to a more specific changeset. llvm-svn: 287367
* Resubmit "Remove an output-parameter from Variable function".Zachary Turner2016-11-181-109/+77
| | | | | | | | | | | The scanning algorithm had a few little subtleties that I overlooked, but this patch should fix everything. I still haven't changed the function to take a StringRef since that has some trickle down effect and is mostly mechanical, I just wanted to get the tricky part as isolated as possible. llvm-svn: 287354
* Revert "Remove an out param from ValueObject::GetValueForExpressionPath."Zachary Turner2016-11-181-4/+50
| | | | | | | This reverts commit r287315, as it introduces a bug that breaks many things. llvm-svn: 287320
* Remove an out param from ValueObject::GetValueForExpressionPath.Zachary Turner2016-11-181-50/+4
| | | | | | | | | | This argument was only used in one place in the codebase, and it was in a non-critical log statement and can be easily substituted for an equally meaningful field instead. The payoff of computing this value is not worth the added complexity. llvm-svn: 287315
* Delete more dead code in ValueObject.Zachary Turner2016-11-181-394/+0
| | | | | | | | Apparently these two enormous functions were dead. Which is good, since one was largely a copy of another function with only a few minor tweaks. llvm-svn: 287308
* Remove some dead code in ValueObject.Zachary Turner2016-11-181-44/+21
| | | | | | | | | Originally I converted this entire function and all dependents to use StringRef, but there were some test failures that were tricky to track down, as this is a complicated function. So I'm starting over, this time in smaller increments. llvm-svn: 287307
* Don't allow direct access to StreamString's internal buffer.Zachary Turner2016-11-161-27/+25
| | | | | | | | | | | | | | | This is a large API change that removes the two functions from StreamString that return a std::string& and a const std::string&, and instead provide one function which returns a StringRef. Direct access to the underlying buffer violates the concept of a "stream" which is intended to provide forward only access, and makes porting to llvm::raw_ostream more difficult in the future. Differential Revision: https://reviews.llvm.org/D26698 llvm-svn: 287152
* Change ValueObject creation functions to take StringRefs.Zachary Turner2016-11-131-13/+14
| | | | llvm-svn: 286744
* Simplify the PrintableRepresentationSpecialCases code; we never used the ↵Enrico Granata2016-11-071-4/+3
| | | | | | ePrintableRepresentationSpecialCasesOnly value and with enum classes the names doesn't need to be that long llvm-svn: 286176
* Fix Clang-tidy readability-redundant-string-cstr warningsMalcolm Parsons2016-11-021-1/+1
| | | | | | | | | | Reviewers: zturner, labath Subscribers: tberghammer, danalbert, lldb-commits Differential Revision: https://reviews.llvm.org/D26233 llvm-svn: 285855
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-3967/+3408
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* Check for nullEnrico Granata2016-09-021-0/+7
| | | | llvm-svn: 280513
* Teach ValueObject::ReadPointedString how to read char[] in host memoryEnrico Granata2016-08-301-5/+16
| | | | llvm-svn: 280166
* "frame variable" and "target variable" shouldn't allow us to get the address ↵Greg Clayton2016-07-061-14/+18
| | | | | | | | | | | | | | of bitfields. "frame variable" and "target variable" are trying to emulate the expression parser when doing things like: (lldb) frame variable &my_struct.my_bitfield And since the expression parser doesn't allow this, we shouldn't allow "frame variable" or "target variable" to succeed. <rdar://problem/27208607> llvm-svn: 274703
* 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
OpenPOWER on IntegriCloud