summaryrefslogtreecommitdiffstats
path: root/lldb/source/Core/ValueObject.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Delete commented-out code.Adrian Prantl2018-10-161-2/+0
| | | | llvm-svn: 344648
* Move RegisterValue,Scalar,State from Core to UtilityPavel Labath2018-08-071-2/+2
| | | | | | | | | | | | | These three classes have no external dependencies, but they are used from various low-level APIs. Moving them down to Utility improves overall code layering (although it still does not break any particular dependency completely). The XCode project will need to be updated after this change. Differential Revision: https://reviews.llvm.org/D49740 llvm-svn: 339127
* Forward declare DumpValueObjectOptions in ValueObject.hRaphael Isemann2018-05-261-0/+1
| | | | | | | | | | | | Summary: This resolves unnecessary the header dependency from Core to DataFormatters. Patch is necessary for the introduction of C++ modules to the LLDB build system. Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D47409 llvm-svn: 333342
* Refactor GetNextPersistentVariableName into a non-virtual methodAdrian Prantl2018-04-301-1/+3
| | | | | | | | | | | | that takes a prefix string. This simplifies the implementation and allows plugins such as the Swift plugin to supply different prefixes for return and error variables. rdar://problem/39299889 Differential Revision: https://reviews.llvm.org/D46088 llvm-svn: 331235
* Move the persistent variable counter into TargetAdrian Prantl2018-04-301-1/+1
| | | | | | | | | | | | | | | | | so it can be shared across multiple language plugins. In a multi-language project it is counterintuitive to have a result variables reuse numbers just because they are using a different language plugin in LLDB (but not for example, when they are Objective-C versus C++, since they are both handled by Clang). This is NFC on llvm.org except for the Go plugin. rdar://problem/39299889 Differential Revision: https://reviews.llvm.org/D46083 llvm-svn: 331234
* Reflow paragraphs in comments.Adrian Prantl2018-04-301-120/+105
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
* Rename Error -> Status.Zachary Turner2017-05-121-18/+18
| | | | | | | | | | | | | | | This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
* Use llvm::ArrayRef rather than std::vector/std::initializer lists for someLang Hames2017-04-261-30/+4
| | | | | | | | | | | ValueObject methods. Using ArrayRef allows us to remove some overloads, work with more array-like types, and avoid some std::vector temporaries. https://reviews.llvm.org/D32518 llvm-svn: 301441
* iwyu fixes for lldbCore.Zachary Turner2017-04-061-25/+40
| | | | | | | | | | | | | | This adjusts header file includes for headers and source files in Core. In doing so, one dependency cycle is eliminated because all the includes from Core to that project were dead includes anyway. In places where some files in other projects were only compiling due to a transitive include from another header, fixups have been made so that those files also include the header they need. Tested on Windows and Linux, and plan to address failures on OSX and FreeBSD after watching the bots. llvm-svn: 299714
* Stop calling ValueObject::SetName from synthetic child providersTamas Berghammer2017-03-311-0/+4
| | | | | | | | | | | | | | | Summary: Calling ValueObject::SetName from a sythetic child provider would change the underying value object used for the non-synthetic child as well what is clearly unintentional. Reviewers: jingham, labath Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D31371 llvm-svn: 299259
* Add support for sythetic operator dereferenceTamas Berghammer2017-03-311-0/+5
| | | | | | | | | | | | | | | | Summary: After this change a sythetic child provider can generate a special child named "$$dereference$$" what if present is used when "operator*" or "operator->" used on a ValueObject. The goal of the change is to make expressions like "up->foo" work inside the "frame variable" command. Reviewers: labath, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D31368 llvm-svn: 299251
* Move DataBuffer / DataExtractor and friends from Core -> Utility.Zachary Turner2017-03-041-1/+1
| | | | llvm-svn: 296943
* Move Log from Core -> Utility.Zachary Turner2017-03-031-1/+1
| | | | | | | | | All references to Host and Core have been removed, so this class can now safely be lowered into Utility. Differential Revision: https://reviews.llvm.org/D30559 llvm-svn: 296909
* Remove dependencies from Utility to Core and Target.Zachary Turner2017-02-141-1/+1
| | | | | | | | | | With this patch, the only dependency left is from Utility to Host. After this is broken, Utility will finally be standalone. Differential Revision: https://reviews.llvm.org/D29909 llvm-svn: 295088
* Move classes from Core -> Utility.Zachary Turner2017-02-021-1/+1
| | | | | | | | | | | | | | | | | | | | | | | This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
* Fix the variable view in the "gui" curses mode so that variables whose ↵Greg Clayton2016-12-281-0/+95
| | | | | | children change will update correctly. Previously the variable view would update the children once and not change. If you were stepping through code where the dynamic type of a variable would change the value and its children, or a synthetic type (like say for a std::vector<int>), the variable view wouldn't update. Now it caches the children and uses the process stop ID to tell when the children need to be updated. llvm-svn: 290688
* 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
OpenPOWER on IntegriCloud