summaryrefslogtreecommitdiffstats
path: root/lldb/source/Core/ValueObjectCast.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Remove unused and undocumented data_offset parameter (NFC)Adrian Prantl2019-08-081-1/+1
| | | | | | | | | Value::GetValueAsData() takes an undocumented parameter called data_offset that is always 0. Differential Revision: https://reviews.llvm.org/D65910 llvm-svn: 368330
* Pass ConstString by value (NFC)Adrian Prantl2019-03-061-2/+2
| | | | | | | | | | | | | | | | | My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed. ConstString has exactly one const char * data member, so passing a ConstString by reference is not any more efficient than copying it by value. In both cases a single pointer is passed. But passing it by value makes it harder to accidentally return the address of a local object. (This fixes rdar://problem/48640859 for the Apple folks) Differential Revision: https://reviews.llvm.org/D59030 llvm-svn: 355553
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Remove comments after header includes.Jonas Devlieghere2018-11-111-2/+2
| | | | | | | | | | This patch removes the comments following the header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain. Differential revision: https://reviews.llvm.org/D54385 llvm-svn: 346625
* Fix (and improve) the support for C99 variable length array typesAdrian Prantl2018-11-051-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Clang recently improved its DWARF support for C VLA types. The DWARF now looks like this: 0x00000051: DW_TAG_variable [4] DW_AT_location( fbreg -32 ) DW_AT_name( "__vla_expr" ) DW_AT_type( {0x000000d3} ( long unsigned int ) ) DW_AT_artificial( true ) ... 0x000000da: DW_TAG_array_type [10] * DW_AT_type( {0x000000cc} ( int ) ) 0x000000df: DW_TAG_subrange_type [11] DW_AT_type( {0x000000e9} ( __ARRAY_SIZE_TYPE__ ) ) DW_AT_count( {0x00000051} ) Without this patch LLDB will naively interpret the DIE offset 0x51 as the static size of the array, which is clearly wrong. This patch extends ValueObject::GetNumChildren to query the dynamic properties of incomplete array types. See the testcase for an example: 4 int foo(int a) { 5 int vla[a]; 6 for (int i = 0; i < a; ++i) 7 vla[i] = i; 8 -> 9 pause(); // break here 10 return vla[a-1]; 11 } (lldb) fr v vla (int []) vla = ([0] = 0, [1] = 1, [2] = 2, [3] = 3) (lldb) quit rdar://problem/21814005 Differential Revision: https://reviews.llvm.org/D53530 llvm-svn: 346165
* Move RegisterValue,Scalar,State from Core to UtilityPavel Labath2018-08-071-1/+1
| | | | | | | | | | | | | 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
* Reflow paragraphs in comments.Adrian Prantl2018-04-301-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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-1/+1
| | | | | | | | | | | | | | | 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
* iwyu fixes for lldbCore.Zachary Turner2017-04-061-17/+6
| | | | | | | | | | | | | | 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
* 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
* [lldb] Fix typos in file headersAlexander Shaposhnikov2016-11-261-2/+1
| | | | | | | | | | | | | This diff fixes typos in file headers (incorrect file names). Test plan: Under llvm/tools/lldb/source: find ./* -type f | grep -e '\(cpp\|h\)$' | while read F; do B=$(basename $F); echo $F head -n 1 $F | grep -v $B | wc -l ; done Differential revision: https://reviews.llvm.org/D27115 llvm-svn: 287966
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-82/+57
| | | | | | | | | | | | | | | | | | | | | | | *** 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
* [SBValue] Add a method GetNumChildren(uint32_t max)Siva Chandra2015-10-211-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix a problem where LLDB could sometimes try to get the size of an ↵Enrico Granata2015-10-141-1/+2
| | | | | | Objective-C type without passing an appropriate ExecutionContext llvm-svn: 250339
* Rename clang_type -> compiler_type for variables.Bruce Mitchener2015-09-241-3/+3
| | | | | | | | | | Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13102 llvm-svn: 248461
* Purge a few places where *LanguageRuntime.h was being used when it Jim Ingham2015-09-031-1/+0
| | | | | | wasn't needed. llvm-svn: 246744
* Final bit of type system cleanup that abstracts declaration contexts into ↵Greg Clayton2015-08-241-5/+5
| | | | | | | | | | | | | | | | | | | | 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
* ClangASTType is now CompilerType.Greg Clayton2015-08-111-5/+5
| | | | | | This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc). llvm-svn: 244689
* Extend synthetic children to produce synthetic values (as in, those that ↵Enrico Granata2014-10-081-1/+1
| | | | | | | | | | | | | | | | | 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
* Huge change to clean up types.Greg Clayton2013-07-111-14/+11
| | | | | | | | A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error. This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness. llvm-svn: 186130
* <rdar://problem/13421412>Greg Clayton2013-03-141-1/+1
| | | | | | Many "byte size" members and variables were using a mixture of uint32_t and size_t. Switching over to using uint64_t everywhere. llvm-svn: 177091
* <rdar://problem/13069948>Greg Clayton2013-01-251-1/+1
| | | | | | | | | | | | Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary. So I defined a new "lldb::offset_t" which should be used for all file offsets. After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed. Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections. llvm-svn: 173463
* Moving ValueObjectCast over to its own .h/.cpp files instead of sharing ↵Enrico Granata2012-10-271-0/+132
ValueObjectDynamic.h/.cpp Removing the IsDynamic() and GetStaticValue() calls, so that they will default to the base class behavior: - non-dynamic - itself as the static value This is in contrast with the previous behavior which could be confusing and could potentially cause issues when using those objects llvm-svn: 166857
OpenPOWER on IntegriCloud