replica
/
hanchenye-llvm-project
2
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
hanchenye-llvm-project/lldb/source/Core/ValueObject.cpp

3448 lines
118 KiB
C++
Raw Normal View History

Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//===-- ValueObject.cpp -----------------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "lldb/Core/ValueObject.h"
iwyu fixes for lldbCore. 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
2017-04-07 05:28:29 +08:00
#include "lldb/Core/Address.h" // for Address
<rdar://problem/11757916> Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes: - Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". - modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly - Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was. - modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile() Cleaned up header includes a bit as well. llvm-svn: 162860
2012-08-30 05:13:06 +08:00
#include "lldb/Core/Module.h"
iwyu fixes for lldbCore. 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
2017-04-07 05:28:29 +08:00
#include "lldb/Core/Scalar.h" // for Scalar
Moving ValueObjectCast over to its own .h/.cpp files instead of sharing 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
2012-10-27 10:05:48 +08:00
#include "lldb/Core/ValueObjectCast.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Core/ValueObjectChild.h"
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
#include "lldb/Core/ValueObjectConstResult.h"
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-04-16 08:01:13 +08:00
#include "lldb/Core/ValueObjectDynamicValue.h"
Added the ability to cast pointer types to another type, no matter what the ValueObject is, as long as the ValueObject that is being asked to be casted is a pointer itself. llvm-svn: 130966
2011-05-06 07:32:56 +08:00
#include "lldb/Core/ValueObjectMemory.h"
when typing a summary string you can use the %S symbol to explicitly indicate that you want the summary to be used to print the target object (e.g. ${var%S}). this might already be the default if your variable is of an aggregate type new feature: synthetic filters. you can restrict the number of children for your variables to only a meaningful subset - the restricted list of children obeys the typical rules (e.g. summaries prevail over children) - one-line summaries show only the filtered (synthetic) children, if you type an expanded summary string, or you use Python scripts, all the real children are accessible - to provide a synthetic children list use the "type synth add" command, as in: type synth add foo_type --child varA --child varB[0] --child varC->packet->flags[1-4] (you can use ., ->, single-item array operator [N] and bitfield operator [N-M]; array slice access is not supported, giving simplified names to expression paths is not supported) - a new -S option to frame variable and target variable lets you override synthetic children and instead show real ones llvm-svn: 135731
2011-07-22 08:16:08 +08:00
#include "lldb/Core/ValueObjectSyntheticFilter.h"
<rdar://problem/12978143> Data formatters now cache themselves. This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval. Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization. The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime. Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type. Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose. llvm-svn: 173728
2013-01-29 07:47:25 +08:00
#include "lldb/DataFormatters/DataVisualization.h"
iwyu fixes for lldbCore. 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
2017-04-07 05:28:29 +08:00
#include "lldb/DataFormatters/FormatManager.h" // for FormatManager
Also port the C string reading code in ValueObject over to using StringPrinter API llvm-svn: 220917
2014-10-31 02:27:31 +08:00
#include "lldb/DataFormatters/StringPrinter.h"
iwyu fixes for lldbCore. 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
2017-04-07 05:28:29 +08:00
#include "lldb/DataFormatters/TypeFormat.h" // for TypeFormatImpl_F...
#include "lldb/DataFormatters/TypeSummary.h" // for TypeSummaryOptions
#include "lldb/DataFormatters/TypeValidator.h" // for TypeValidatorImp...
<rdar://problem/14393032> DumpValueObject() 2.0 This checkin restores pre-Xcode5 functionality to the "po" (expr -O) command: - expr now has a new --description-verbosity (-v) argument, which takes either compact or full as a value (-v is the same as -vfull) When the full mode is on, "po" will show the extended output with type name, persistent variable name and value, as in (lldb) expr -O -v -- foo (id) $0 = 0x000000010010baf0 { 1 = 2; 2 = 3; } When -v is omitted, or -vcompact is passed, the Xcode5-style output will be shown, as in (lldb) expr -O -- foo { 1 = 2; 2 = 3; } - for a non-ObjectiveC object, LLDB will still try to retrieve a summary and/or value to display (lldb) po 5 5 -v also works in this mode (lldb) expr -O -vfull -- 5 (int) $4 = 5 On top of that, this is a major refactoring of the ValueObject printing code. The functionality is now factored into a ValueObjectPrinter class for easier maintenance in the future DumpValueObject() was turned into an instance method ValueObject::Dump() which simply calls through to the printer code, Dump_Impl has been removed Test case to follow llvm-svn: 191694
2013-10-01 03:11:51 +08:00
#include "lldb/DataFormatters/ValueObjectPrinter.h"
iwyu fixes for lldbCore. 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
2017-04-07 05:28:29 +08:00
#include "lldb/Expression/ExpressionVariable.h" // for ExpressionVariable
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Symbol/ClangASTContext.h"
Introduce the notion of "type summary options" as flags that can be passed 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
2014-11-07 05:23:20 +08:00
#include "lldb/Symbol/CompileUnit.h"
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
#include "lldb/Symbol/CompilerType.h"
iwyu fixes for lldbCore. 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
2017-04-07 05:28:29 +08:00
#include "lldb/Symbol/Declaration.h" // for Declaration
#include "lldb/Symbol/SymbolContext.h" // for SymbolContext
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Symbol/Type.h"
Move the "Object Description" into the ValueObject, and the add an API to SBValue to access it. For now this is just the result of ObjC NSPrintForDebugger, but could be extended. Also store the results of the ObjC Object Printer in a Stream, not a ConstString. llvm-svn: 113660
2010-09-11 07:12:17 +08:00
#include "lldb/Target/ExecutionContext.h"
Change ValueObject::IsLogicalTrue so that it starts by asking the applicable Language plugin before using the C-style rule llvm-svn: 251838
2015-11-03 05:52:05 +08:00
#include "lldb/Target/Language.h"
Replace the vestigial Value::GetOpaqueCLangQualType with the more correct Value::GetValueOpaqueClangQualType. But mostly, move the ObjC Trampoline handling code from the MacOSX dyld plugin to the AppleObjCRuntime classes. llvm-svn: 114935
2010-09-28 09:25:32 +08:00
#include "lldb/Target/LanguageRuntime.h"
Fixed a bug where a variable could not be formatted in a summary if its datatype already had a custom format Fixed a bug where Objective-C variables coming out of the expression parser could crash the Python synthetic providers: - expression parser output has a "frozen data" component, which is a byte-exact copy of the value (in host memory), if trying to read into memory based on the host address, LLDB would crash. we are now passing the correct (target) pointer to the Python code Objective-C "id" variables are now formatted according to their dynamic type, if the -d option to frame variable is used: - Code based on the Objective-C 2.0 runtime is used to obtain this information without running code on the target llvm-svn: 136695
2011-08-03 01:27:39 +08:00
#include "lldb/Target/ObjCLanguageRuntime.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Target/Process.h"
iwyu fixes for lldbCore. 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
2017-04-07 05:28:29 +08:00
#include "lldb/Target/StackFrame.h" // for StackFrame
Moved the section load list up into the target so we can use the target to symbolicate things without the need for a valid process subclass. llvm-svn: 113895
2010-09-15 07:36:40 +08:00
#include "lldb/Target/Target.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include "lldb/Target/Thread.h"
iwyu fixes for lldbCore. 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
2017-04-07 05:28:29 +08:00
#include "lldb/Target/ThreadList.h" // for ThreadList
#include "lldb/Utility/DataBuffer.h" // for DataBuffer
#include "lldb/Utility/DataBufferHeap.h"
#include "lldb/Utility/Flags.h" // for Flags
#include "lldb/Utility/Log.h"
#include "lldb/Utility/Logging.h" // for GetLogIfAllCateg...
#include "lldb/Utility/SharingPtr.h" // for SharingPtr
#include "lldb/Utility/Stream.h" // for Stream
#include "lldb/Utility/StreamString.h"
#include "lldb/lldb-private-types.h" // for RegisterInfo
#include "llvm/Support/Compiler.h" // for LLVM_FALLTHROUGH
#include <algorithm> // for min
#include <cstdint> // for uint32_t, uint64_t
#include <cstdlib> // for size_t, NULL
#include <memory> // for shared_ptr, oper...
#include <tuple> // for tie, tuple
#include <assert.h> // for assert
#include <inttypes.h> // for PRIu64, PRIx64
#include <stdio.h> // for snprintf
#include <string.h> // for memcpy, memcmp
namespace lldb_private {
class ExecutionContextScope;
}
namespace lldb_private {
class SymbolContextScope;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
using namespace lldb;
using namespace lldb_private;
smarter summary strings: - formats %s %char[] %c and %a now work to print 0-terminated c-strings if they are applied to a char* or char[] even without the [] operator (e.g. ${var%s}) - array formats (char[], intN[], ..) now work when applied to an array of a scalar type even without the [] operator (e.g. ${var%int32_t[]}) LLDB will not crash because of endless loop when trying to obtain a summary for an object that has no value and references itself in its summary string In many cases, a wrong summary string will now display an "<error>" message instead of giving out an empty string llvm-svn: 135007
2011-07-13 06:56:10 +08:00
using namespace lldb_utility;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Added the ability for DWARF locations to use the ABI plug-ins to resolve register names when dumping variable locations and location lists. Also did some cleanup where "int" types were being used for "lldb::RegisterKind" values. llvm-svn: 138988
2011-09-02 09:15:17 +08:00
static user_id_t g_value_obj_uid = 0;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//----------------------------------------------------------------------
// ValueObject constructor
//----------------------------------------------------------------------
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ValueObject::ValueObject(ValueObject &parent)
: UserID(++g_value_obj_uid), // Unique identifier for every value object
m_parent(&parent), m_root(NULL), m_update_point(parent.GetUpdatePoint()),
m_name(), m_data(), m_value(), m_error(), m_value_str(),
m_old_value_str(), m_location_str(), m_summary_str(), m_object_desc_str(),
m_validation_result(), m_manager(parent.GetManager()), m_children(),
m_synthetic_children(), m_dynamic_value(NULL), m_synthetic_value(NULL),
m_deref_valobj(NULL), m_format(eFormatDefault),
m_last_format(eFormatDefault), m_last_format_mgr_revision(0),
m_type_summary_sp(), m_type_format_sp(), m_synthetic_children_sp(),
m_type_validator_sp(), m_user_id_of_forced_summary(),
m_address_type_of_ptr_or_ref_children(eAddressTypeInvalid),
m_value_checksum(),
m_preferred_display_language(lldb::eLanguageTypeUnknown),
m_language_flags(0), m_value_is_valid(false), m_value_did_change(false),
m_children_count_valid(false), m_old_value_valid(false),
m_is_deref_of_parent(false), m_is_array_item_for_pointer(false),
m_is_bitfield_for_scalar(false), m_is_child_at_offset(false),
m_is_getting_summary(false),
m_did_calculate_complete_objc_class_type(false),
m_is_synthetic_children_generated(
parent.m_is_synthetic_children_generated) {
m_manager->ManageObject(this);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
//----------------------------------------------------------------------
Convert ValueObject to explicitly maintain the Execution Context in which they were created, and then use that when they update themselves. That means all the ValueObject evaluate me type functions that used to require a Frame object now do not. I didn't remove the SBValue API's that take this now useless frame, but I added ones that don't require the frame, and marked the SBFrame taking ones as deprecated. llvm-svn: 128593
2011-03-31 08:19:25 +08:00
// ValueObject constructor
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//----------------------------------------------------------------------
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ValueObject::ValueObject(ExecutionContextScope *exe_scope,
AddressType child_ptr_or_ref_addr_type)
: UserID(++g_value_obj_uid), // Unique identifier for every value object
m_parent(NULL), m_root(NULL), m_update_point(exe_scope), m_name(),
m_data(), m_value(), m_error(), m_value_str(), m_old_value_str(),
m_location_str(), m_summary_str(), m_object_desc_str(),
m_validation_result(), m_manager(), m_children(), m_synthetic_children(),
m_dynamic_value(NULL), m_synthetic_value(NULL), m_deref_valobj(NULL),
m_format(eFormatDefault), m_last_format(eFormatDefault),
m_last_format_mgr_revision(0), m_type_summary_sp(), m_type_format_sp(),
m_synthetic_children_sp(), m_type_validator_sp(),
m_user_id_of_forced_summary(),
m_address_type_of_ptr_or_ref_children(child_ptr_or_ref_addr_type),
m_value_checksum(),
m_preferred_display_language(lldb::eLanguageTypeUnknown),
m_language_flags(0), m_value_is_valid(false), m_value_did_change(false),
m_children_count_valid(false), m_old_value_valid(false),
m_is_deref_of_parent(false), m_is_array_item_for_pointer(false),
m_is_bitfield_for_scalar(false), m_is_child_at_offset(false),
m_is_getting_summary(false),
m_did_calculate_complete_objc_class_type(false),
m_is_synthetic_children_generated(false) {
m_manager = new ValueObjectManager();
m_manager->ManageObject(this);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Convert ValueObject to explicitly maintain the Execution Context in which they were created, and then use that when they update themselves. That means all the ValueObject evaluate me type functions that used to require a Frame object now do not. I didn't remove the SBValue API's that take this now useless frame, but I added ones that don't require the frame, and marked the SBFrame taking ones as deprecated. llvm-svn: 128593
2011-03-31 08:19:25 +08:00
//----------------------------------------------------------------------
// Destructor
//----------------------------------------------------------------------
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ValueObject::~ValueObject() {}
bool ValueObject::UpdateValueIfNeeded(bool update_format) {
bool did_change_formats = false;
if (update_format)
did_change_formats = UpdateFormatsIfNeeded();
// If this is a constant value, then our success is predicated on whether
// we have an error or not
if (GetIsConstant()) {
// if you are constant, things might still have changed behind your back
// (e.g. you are a frozen object and things have changed deeper than you
// cared to freeze-dry yourself)
// in this case, your value has not changed, but "computed" entries might
// have, so you might now have
// a different summary, or a different object description. clear these so we
// will recompute them
if (update_format && !did_change_formats)
ClearUserVisibleData(eClearUserVisibleDataItemsSummary |
eClearUserVisibleDataItemsDescription);
return m_error.Success();
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
bool first_update = IsChecksumEmpty();
if (NeedsUpdating()) {
m_update_point.SetUpdated();
// Save the old value using swap to avoid a string copy which
// also will clear our m_value_str
if (m_value_str.empty()) {
m_old_value_valid = false;
} else {
m_old_value_valid = true;
m_old_value_str.swap(m_value_str);
ClearUserVisibleData(eClearUserVisibleDataItemsValue);
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-07 03:20:51 +08:00
}
Added the notion that a value object can be constant by adding: bool ValueObject::GetIsConstant() const; void ValueObject::SetIsConstant(); This will stop anything from being re-evaluated within the value object so that constant result value objects can maintain their frozen values without anything being updated or changed within the value object. Made it so the ValueObjectConstResult can be constructed with an lldb_private::Error object to allow for expression results to have errors. Since ValueObject objects contain error objects, I changed the expression evaluation in ClangUserExpression from static Error ClangUserExpression::Evaluate (ExecutionContext &exe_ctx, const char *expr_cstr, lldb::ValueObjectSP &result_valobj_sp); to: static lldb::ValueObjectSP Evaluate (ExecutionContext &exe_ctx, const char *expr_cstr); Even though expression parsing is borked right now (pending fixes coming from Sean Callanan), I filled in the implementation for: SBValue SBFrame::EvaluateExpression (const char *expr); Modified all expression code to deal with the above changes. llvm-svn: 115589
2010-10-05 11:13:51 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ClearUserVisibleData();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (IsInScope()) {
const bool value_was_valid = GetValueIsValid();
SetValueDidChange(false);
m_error.Clear();
// Call the pure virtual function to update the value
bool need_compare_checksums = false;
llvm::SmallVector<uint8_t, 16> old_checksum;
if (!first_update && CanProvideValue()) {
need_compare_checksums = true;
old_checksum.resize(m_value_checksum.size());
std::copy(m_value_checksum.begin(), m_value_checksum.end(),
old_checksum.begin());
}
bool success = UpdateValue();
SetValueIsValid(success);
if (success) {
const uint64_t max_checksum_size = 128;
m_data.Checksum(m_value_checksum, max_checksum_size);
} else {
need_compare_checksums = false;
m_value_checksum.clear();
}
assert(!need_compare_checksums ||
(!old_checksum.empty() && !m_value_checksum.empty()));
if (first_update)
SetValueDidChange(false);
else if (!m_value_did_change && success == false) {
// The value wasn't gotten successfully, so we mark this
// as changed if the value used to be valid and now isn't
SetValueDidChange(value_was_valid);
} else if (need_compare_checksums) {
SetValueDidChange(memcmp(&old_checksum[0], &m_value_checksum[0],
m_value_checksum.size()));
}
} else {
m_error.SetErrorString("out of scope");
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
return m_error.Success();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
bool ValueObject::UpdateFormatsIfNeeded() {
Log *log(lldb_private::GetLogIfAllCategoriesSet(LIBLLDB_LOG_DATAFORMATTERS));
if (log)
log->Printf("[%s %p] checking for FormatManager revisions. ValueObject "
"rev: %d - Global rev: %d",
GetName().GetCString(), static_cast<void *>(this),
m_last_format_mgr_revision,
DataVisualization::GetCurrentRevision());
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
bool any_change = false;
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if ((m_last_format_mgr_revision != DataVisualization::GetCurrentRevision())) {
m_last_format_mgr_revision = DataVisualization::GetCurrentRevision();
any_change = true;
SetValueFormat(DataVisualization::GetFormat(*this, eNoDynamicValues));
SetSummaryFormat(
DataVisualization::GetSummaryFormat(*this, GetDynamicValueType()));
Add LLDB_DISABLE_PYTHON around newly added methods in DataVisualization.h / DataVisualization.cpp / ValueObject.cpp and FormatManager.h / FormatManager.cpp llvm-svn: 156886
2012-05-16 08:38:08 +08:00
#ifndef LLDB_DISABLE_PYTHON
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
SetSyntheticChildren(
DataVisualization::GetSyntheticChildren(*this, GetDynamicValueType()));
Add LLDB_DISABLE_PYTHON around newly added methods in DataVisualization.h / DataVisualization.cpp / ValueObject.cpp and FormatManager.h / FormatManager.cpp llvm-svn: 156886
2012-05-16 08:38:08 +08:00
#endif
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
SetValidator(DataVisualization::GetValidator(*this, GetDynamicValueType()));
}
sweep up -Wformat warnings from gcc This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
2014-04-04 12:06:10 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
return any_change;
This commit adds a new top subcommand "summary" to command type named "type". Currently this command implements three commands: type summary add <format> <typename1> [<typename2> ...] type summary delete <typename1> [<typename2> ...] type summary list [<typename1> [<typename2>] ...] type summary clear This allows you to specify the default format that will be used to display summaries for variables, shown when you use "frame variable" or "expression", or the SBValue classes. Examples: type summary add "x = ${var.x}" Point type summary list type summary add --one-liner SimpleType llvm-svn: 134108
2011-06-30 06:27:15 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
void ValueObject::SetNeedsUpdate() {
m_update_point.SetNeedsUpdate();
// We have to clear the value string here so ConstResult children will notice
// if their values are
// changed by hand (i.e. with SetValueAsCString).
ClearUserVisibleData(eClearUserVisibleDataItemsValue);
Make ValueObject::SetValueFromCString work correctly. Also change the SourceInitFile to look for .lldb-<APPNAME> and source that preferentially if it exists. Also made the breakpoint site report its address as well as its breakpoint number when it gets hit and can't find any the associated locations (usually because the breakpoint got disabled or deleted programmatically between the time it was hit and reported.) Changed ThreadPlanCallFunction to initialize the ivar m_func in the initializers of the constructor, rather than waiting to initialize till later on in the function. Fixed a bug where if you make an SBError and the ask it Success, it returns false. Fixed ValueObject::ResolveValue so that it resolves a temporary value, rather than overwriting the one in the value object. llvm-svn: 137536
2011-08-13 07:34:31 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
void ValueObject::ClearDynamicTypeInformation() {
m_children_count_valid = false;
m_did_calculate_complete_objc_class_type = false;
m_last_format_mgr_revision = 0;
m_override_type = CompilerType();
SetValueFormat(lldb::TypeFormatImplSP());
SetSummaryFormat(lldb::TypeSummaryImplSP());
SetSyntheticChildren(lldb::SyntheticChildrenSP());
<rdar://problem/12503640> Fixing an issue where the dynamic type of an Objective-C pointer changed but we still reported the one-true-definition for the previous type. This was causing issues where a variable could be reported as being of an entirely different type after an assignment llvm-svn: 166119
2012-10-18 03:03:34 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
CompilerType ValueObject::MaybeCalculateCompleteType() {
CompilerType compiler_type(GetCompilerTypeImpl());
if (m_did_calculate_complete_objc_class_type) {
if (m_override_type.IsValid())
return m_override_type;
Added support for looking up the complete type for Objective-C classes. This allows LLDB to find ivars declared in class extensions in modules other than where the debugger is currently stopped (we already supported this when the debugger was stopped in the same module as the definition). This involved the following main changes: - The ObjCLanguageRuntime now knows how to hunt for the authoritative version of an Objective-C type. It looks for the symbol indicating a definition, and then gets the type from the module containing that symbol. - ValueObjects now report their type with a potential override, and the override is set if the type of the ValueObject is an Objective-C class or pointer type that is defined somewhere other than the original reported type. This means that "frame variable" will always use the complete type if one is available. - The ClangASTSource now looks for the complete type when looking for ivars. This means that "expr" will always use the complete type if one is available. - I added a testcase that verifies that both "frame variable" and "expr" work. llvm-svn: 151214
2012-02-23 07:57:45 +08:00
else
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
return compiler_type;
}
CompilerType class_type;
bool is_pointer_type = false;
if (ClangASTContext::IsObjCObjectPointerType(compiler_type, &class_type)) {
is_pointer_type = true;
} else if (ClangASTContext::IsObjCObjectOrInterfaceType(compiler_type)) {
class_type = compiler_type;
} else {
Rename clang_type -> compiler_type for variables. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13102 llvm-svn: 248461
2015-09-24 11:54:50 +08:00
return compiler_type;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Added support for looking up the complete type for Objective-C classes. This allows LLDB to find ivars declared in class extensions in modules other than where the debugger is currently stopped (we already supported this when the debugger was stopped in the same module as the definition). This involved the following main changes: - The ObjCLanguageRuntime now knows how to hunt for the authoritative version of an Objective-C type. It looks for the symbol indicating a definition, and then gets the type from the module containing that symbol. - ValueObjects now report their type with a potential override, and the override is set if the type of the ValueObject is an Objective-C class or pointer type that is defined somewhere other than the original reported type. This means that "frame variable" will always use the complete type if one is available. - The ClangASTSource now looks for the complete type when looking for ivars. This means that "expr" will always use the complete type if one is available. - I added a testcase that verifies that both "frame variable" and "expr" work. llvm-svn: 151214
2012-02-23 07:57:45 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
m_did_calculate_complete_objc_class_type = true;
Added support for looking up the complete type for Objective-C classes. This allows LLDB to find ivars declared in class extensions in modules other than where the debugger is currently stopped (we already supported this when the debugger was stopped in the same module as the definition). This involved the following main changes: - The ObjCLanguageRuntime now knows how to hunt for the authoritative version of an Objective-C type. It looks for the symbol indicating a definition, and then gets the type from the module containing that symbol. - ValueObjects now report their type with a potential override, and the override is set if the type of the ValueObject is an Objective-C class or pointer type that is defined somewhere other than the original reported type. This means that "frame variable" will always use the complete type if one is available. - The ClangASTSource now looks for the complete type when looking for ivars. This means that "expr" will always use the complete type if one is available. - I added a testcase that verifies that both "frame variable" and "expr" work. llvm-svn: 151214
2012-02-23 07:57:45 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (class_type) {
ConstString class_name(class_type.GetConstTypeName());
<rdar://problem/15144376> This commit reimplements the TypeImpl class (the class that backs SBType) in terms of a static,dynamic type pair This is useful for those cases when the dynamic type of an ObjC variable can only be obtained in terms of an "hollow" type with no ivars In that case, we could either go with the static type (+iVar information) or with the dynamic type (+inheritance chain) With the new TypeImpl implementation, we try to combine these two sources of information in order to extract as much information as possible This should improve the functionality of tools that are using the SBType API to do extensive dynamic type inspection llvm-svn: 193564
2013-10-29 08:28:35 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (class_name) {
ProcessSP process_sp(
GetUpdatePoint().GetExecutionContextRef().GetProcessSP());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (process_sp) {
ObjCLanguageRuntime *objc_language_runtime(
process_sp->GetObjCLanguageRuntime());
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (objc_language_runtime) {
TypeSP complete_objc_class_type_sp =
objc_language_runtime->LookupInCompleteClassCache(class_name);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (complete_objc_class_type_sp) {
CompilerType complete_class(
complete_objc_class_type_sp->GetFullCompilerType());
<rdar://problem/13695846> Enabling LLDB to write to variables that are stored in registers Previously, this would not work since the Value's Context loses the notion of the data being in a register We now store an "original" context that comes out of DWARF parsing, and use that context's data when attempting a write llvm-svn: 180803
2013-05-01 04:45:04 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (complete_class.GetCompleteType()) {
if (is_pointer_type) {
m_override_type = complete_class.GetPointerType();
} else {
m_override_type = complete_class;
}
if (m_override_type.IsValid())
return m_override_type;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
return compiler_type;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
CompilerType ValueObject::GetCompilerType() {
return MaybeCalculateCompleteType();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
TypeImpl ValueObject::GetTypeImpl() { return TypeImpl(GetCompilerType()); }
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
DataExtractor &ValueObject::GetDataExtractor() {
UpdateValueIfNeeded(false);
return m_data;
Added support for loading and unloading shared libraries. This was done by adding support into lldb_private::Process: virtual uint32_t lldb_private::Process::LoadImage (const FileSpec &image_spec, Error &error); virtual Error lldb_private::Process::UnloadImage (uint32_t image_token); There is a default implementation that should work for both linux and MacOSX. This ability has also been exported through the SBProcess API: uint32_t lldb::SBProcess::LoadImage (lldb::SBFileSpec &image_spec, lldb::SBError &error); lldb::SBError lldb::SBProcess::UnloadImage (uint32_t image_token); Modified the DynamicLoader plug-in interface to require it to be able to tell us if it is currently possible to load/unload a shared library: virtual lldb_private::Error DynamicLoader::CanLoadImage () = 0; This way the dynamic loader plug-ins are allows to veto whether we can currently load a shared library since the dynamic loader might know if it is currenlty loading/unloading shared libraries. It might also know about the current host system and know where to check to make sure runtime or malloc locks are currently being held. Modified the expression parser to have ClangUserExpression::Evaluate() be the one that causes the dynamic checkers to be loaded instead of other code that shouldn't have to worry about it. llvm-svn: 118227
2010-11-04 09:54:29 +08:00
}
Rename Error -> Status. 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
2017-05-12 12:51:55 +08:00
const Status &ValueObject::GetError() {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
UpdateValueIfNeeded(false);
return m_error;
Abstract the notion of the truth value of an expression result, for use in breakpoint conditions. llvm-svn: 251727
2015-10-31 08:02:18 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
const ConstString &ValueObject::GetName() const { return m_name; }
const char *ValueObject::GetLocationAsCString() {
return GetLocationAsCStringImpl(m_value, m_data);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
const char *ValueObject::GetLocationAsCStringImpl(const Value &value,
const DataExtractor &data) {
if (UpdateValueIfNeeded(false)) {
if (m_location_str.empty()) {
StreamString sstr;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Value::ValueType value_type = value.GetValueType();
switch (value_type) {
case Value::eValueTypeScalar:
case Value::eValueTypeVector:
if (value.GetContextType() == Value::eContextTypeRegisterInfo) {
RegisterInfo *reg_info = value.GetRegisterInfo();
if (reg_info) {
if (reg_info->name)
m_location_str = reg_info->name;
else if (reg_info->alt_name)
m_location_str = reg_info->alt_name;
if (m_location_str.empty())
m_location_str = (reg_info->encoding == lldb::eEncodingVector)
? "vector"
: "scalar";
}
}
if (m_location_str.empty())
m_location_str =
(value_type == Value::eValueTypeVector) ? "vector" : "scalar";
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
case Value::eValueTypeLoadAddress:
case Value::eValueTypeFileAddress:
case Value::eValueTypeHostAddress: {
uint32_t addr_nibble_size = data.GetAddressByteSize() * 2;
sstr.Printf("0x%*.*llx", addr_nibble_size, addr_nibble_size,
value.GetScalar().ULongLong(LLDB_INVALID_ADDRESS));
Don't allow direct access to StreamString's internal buffer. 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
2016-11-17 05:15:24 +08:00
m_location_str = sstr.GetString();
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
} break;
}
}
}
return m_location_str.c_str();
}
Value &ValueObject::GetValue() { return m_value; }
const Value &ValueObject::GetValue() const { return m_value; }
bool ValueObject::ResolveValue(Scalar &scalar) {
if (UpdateValueIfNeeded(
false)) // make sure that you are up to date before returning anything
{
ExecutionContext exe_ctx(GetExecutionContextRef());
Value tmp_value(m_value);
scalar = tmp_value.ResolveValue(&exe_ctx);
if (scalar.IsValid()) {
const uint32_t bitfield_bit_size = GetBitfieldBitSize();
if (bitfield_bit_size)
return scalar.ExtractBitfield(bitfield_bit_size,
GetBitfieldBitOffset());
return true;
}
}
return false;
}
Rename Error -> Status. 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
2017-05-12 12:51:55 +08:00
bool ValueObject::IsLogicalTrue(Status &error) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (Language *language = Language::FindPlugin(GetObjectRuntimeLanguage())) {
LazyBool is_logical_true = language->IsLogicalTrue(*this, error);
switch (is_logical_true) {
case eLazyBoolYes:
case eLazyBoolNo:
return (is_logical_true == true);
case eLazyBoolCalculate:
break;
}
}
Scalar scalar_value;
if (!ResolveValue(scalar_value)) {
error.SetErrorString("failed to get a scalar result");
return false;
}
bool ret;
if (scalar_value.ULongLong(1) == 0)
ret = false;
else
ret = true;
error.Clear();
return ret;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
bool ValueObject::GetValueIsValid() const { return m_value_is_valid; }
void ValueObject::SetValueIsValid(bool b) { m_value_is_valid = b; }
bool ValueObject::GetValueDidChange() { return m_value_did_change; }
void ValueObject::SetValueDidChange(bool value_changed) {
m_value_did_change = value_changed;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ValueObjectSP ValueObject::GetChildAtIndex(size_t idx, bool can_create) {
ValueObjectSP child_sp;
// We may need to update our value if we are dynamic
if (IsPossibleDynamicType())
UpdateValueIfNeeded(false);
if (idx < GetNumChildren()) {
// Check if we have already made the child value object?
if (can_create && !m_children.HasChildAtIndex(idx)) {
// No we haven't created the child at this index, so lets have our
// subclass do it and cache the result for quick future access.
m_children.SetChildAtIndex(idx, CreateChildAtIndex(idx, false, 0));
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ValueObject *child = m_children.GetChildAtIndex(idx);
if (child != NULL)
return child->GetSP();
}
return child_sp;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
<rdar://problem/12239827> Providing a data formatter for libc++ std::wstring In the process, refactoring the std::string data formatter to be written in C++ so that commonalities between the two can be exploited Also, providing a new API on the ValueObject to navigate a hierarchy by index-path Lastly, an appropriate test case is included llvm-svn: 172282
2013-01-12 09:00:22 +08:00
lldb::ValueObjectSP
Use llvm::ArrayRef rather than std::vector/std::initializer lists for some 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
2017-04-27 02:15:40 +08:00
ValueObject::GetChildAtIndexPath(llvm::ArrayRef<size_t> idxs,
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
size_t *index_of_error) {
if (idxs.size() == 0)
return GetSP();
ValueObjectSP root(GetSP());
for (size_t idx : idxs) {
root = root->GetChildAtIndex(idx, true);
if (!root) {
if (index_of_error)
*index_of_error = idx;
return root;
<rdar://problem/12239827> Providing a data formatter for libc++ std::wstring In the process, refactoring the std::string data formatter to be written in C++ so that commonalities between the two can be exploited Also, providing a new API on the ValueObject to navigate a hierarchy by index-path Lastly, an appropriate test case is included llvm-svn: 172282
2013-01-12 09:00:22 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
return root;
<rdar://problem/12239827> Providing a data formatter for libc++ std::wstring In the process, refactoring the std::string data formatter to be written in C++ so that commonalities between the two can be exploited Also, providing a new API on the ValueObject to navigate a hierarchy by index-path Lastly, an appropriate test case is included llvm-svn: 172282
2013-01-12 09:00:22 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
lldb::ValueObjectSP ValueObject::GetChildAtIndexPath(
Use llvm::ArrayRef rather than std::vector/std::initializer lists for some 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
2017-04-27 02:15:40 +08:00
llvm::ArrayRef<std::pair<size_t, bool>> idxs, size_t *index_of_error) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (idxs.size() == 0)
return GetSP();
ValueObjectSP root(GetSP());
for (std::pair<size_t, bool> idx : idxs) {
root = root->GetChildAtIndex(idx.first, idx.second);
if (!root) {
if (index_of_error)
*index_of_error = idx.first;
return root;
<rdar://problem/12239827> Providing a data formatter for libc++ std::wstring In the process, refactoring the std::string data formatter to be written in C++ so that commonalities between the two can be exploited Also, providing a new API on the ValueObject to navigate a hierarchy by index-path Lastly, an appropriate test case is included llvm-svn: 172282
2013-01-12 09:00:22 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
return root;
<rdar://problem/12239827> Providing a data formatter for libc++ std::wstring In the process, refactoring the std::string data formatter to be written in C++ so that commonalities between the two can be exploited Also, providing a new API on the ValueObject to navigate a hierarchy by index-path Lastly, an appropriate test case is included llvm-svn: 172282
2013-01-12 09:00:22 +08:00
}
<rdar://problem/14071463> SVN r189964 provided a sample Python script to inspect unordered(multi){set|map} with synthetic children, contribued by Jared Grubb This checkin converts that sample script to a C++ provider built into LLDB A test case is also provided llvm-svn: 190564
2013-09-12 08:48:47 +08:00
lldb::ValueObjectSP
Use llvm::ArrayRef rather than std::vector/std::initializer lists for some 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
2017-04-27 02:15:40 +08:00
ValueObject::GetChildAtNamePath(llvm::ArrayRef<ConstString> names,
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ConstString *name_of_error) {
if (names.size() == 0)
return GetSP();
ValueObjectSP root(GetSP());
for (ConstString name : names) {
root = root->GetChildMemberWithName(name, true);
if (!root) {
if (name_of_error)
*name_of_error = name;
return root;
}
}
return root;
}
lldb::ValueObjectSP ValueObject::GetChildAtNamePath(
Use llvm::ArrayRef rather than std::vector/std::initializer lists for some 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
2017-04-27 02:15:40 +08:00
llvm::ArrayRef<std::pair<ConstString, bool>> names,
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ConstString *name_of_error) {
if (names.size() == 0)
return GetSP();
ValueObjectSP root(GetSP());
for (std::pair<ConstString, bool> name : names) {
root = root->GetChildMemberWithName(name.first, name.second);
if (!root) {
if (name_of_error)
*name_of_error = name.first;
return root;
<rdar://problem/14071463> SVN r189964 provided a sample Python script to inspect unordered(multi){set|map} with synthetic children, contribued by Jared Grubb This checkin converts that sample script to a C++ provider built into LLDB A test case is also provided llvm-svn: 190564
2013-09-12 08:48:47 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
return root;
<rdar://problem/14071463> SVN r189964 provided a sample Python script to inspect unordered(multi){set|map} with synthetic children, contribued by Jared Grubb This checkin converts that sample script to a C++ provider built into LLDB A test case is also provided llvm-svn: 190564
2013-09-12 08:48:47 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
size_t ValueObject::GetIndexOfChildWithName(const ConstString &name) {
bool omit_empty_base_classes = true;
return GetCompilerType().GetIndexOfChildWithName(name.GetCString(),
omit_empty_base_classes);
<rdar://problem/14071463> SVN r189964 provided a sample Python script to inspect unordered(multi){set|map} with synthetic children, contribued by Jared Grubb This checkin converts that sample script to a C++ provider built into LLDB A test case is also provided llvm-svn: 190564
2013-09-12 08:48:47 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ValueObjectSP ValueObject::GetChildMemberWithName(const ConstString &name,
bool can_create) {
// when getting a child by name, it could be buried inside some base
// classes (which really aren't part of the expression path), so we
// need a vector of indexes that can get us down to the correct child
ValueObjectSP child_sp;
// We may need to update our value if we are dynamic
if (IsPossibleDynamicType())
UpdateValueIfNeeded(false);
std::vector<uint32_t> child_indexes;
bool omit_empty_base_classes = true;
const size_t num_child_indexes =
GetCompilerType().GetIndexOfChildMemberWithName(
name.GetCString(), omit_empty_base_classes, child_indexes);
if (num_child_indexes > 0) {
std::vector<uint32_t>::const_iterator pos = child_indexes.begin();
std::vector<uint32_t>::const_iterator end = child_indexes.end();
child_sp = GetChildAtIndex(*pos, can_create);
for (++pos; pos != end; ++pos) {
if (child_sp) {
ValueObjectSP new_child_sp(child_sp->GetChildAtIndex(*pos, can_create));
child_sp = new_child_sp;
} else {
child_sp.reset();
}
}
}
return child_sp;
}
size_t ValueObject::GetNumChildren(uint32_t max) {
UpdateValueIfNeeded();
if (max < UINT32_MAX) {
if (m_children_count_valid) {
size_t children_count = m_children.GetChildrenCount();
return children_count <= max ? children_count : max;
} else
return CalculateNumChildren(max);
}
if (!m_children_count_valid) {
SetNumChildren(CalculateNumChildren());
}
return m_children.GetChildrenCount();
}
bool ValueObject::MightHaveChildren() {
bool has_children = false;
const uint32_t type_info = GetTypeInfo();
if (type_info) {
if (type_info & (eTypeHasChildren | eTypeIsPointer | eTypeIsReference))
has_children = true;
} else {
has_children = GetNumChildren() > 0;
}
return has_children;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
// Should only be called by ValueObject::GetNumChildren()
void ValueObject::SetNumChildren(size_t num_children) {
m_children_count_valid = true;
m_children.SetChildrenCount(num_children);
}
void ValueObject::SetName(const ConstString &name) { m_name = name; }
ValueObject *ValueObject::CreateChildAtIndex(size_t idx,
bool synthetic_array_member,
int32_t synthetic_index) {
ValueObject *valobj = NULL;
bool omit_empty_base_classes = true;
bool ignore_array_bounds = synthetic_array_member;
std::string child_name_str;
uint32_t child_byte_size = 0;
int32_t child_byte_offset = 0;
uint32_t child_bitfield_bit_size = 0;
uint32_t child_bitfield_bit_offset = 0;
bool child_is_base_class = false;
bool child_is_deref_of_parent = false;
uint64_t language_flags = 0;
const bool transparent_pointers = synthetic_array_member == false;
CompilerType child_compiler_type;
ExecutionContext exe_ctx(GetExecutionContextRef());
child_compiler_type = GetCompilerType().GetChildCompilerTypeAtIndex(
&exe_ctx, idx, transparent_pointers, omit_empty_base_classes,
ignore_array_bounds, child_name_str, child_byte_size, child_byte_offset,
child_bitfield_bit_size, child_bitfield_bit_offset, child_is_base_class,
child_is_deref_of_parent, this, language_flags);
if (child_compiler_type) {
if (synthetic_index)
child_byte_offset += child_byte_size * synthetic_index;
ConstString child_name;
if (!child_name_str.empty())
child_name.SetCString(child_name_str.c_str());
valobj = new ValueObjectChild(
*this, child_compiler_type, child_name, child_byte_size,
child_byte_offset, child_bitfield_bit_size, child_bitfield_bit_offset,
child_is_base_class, child_is_deref_of_parent, eAddressTypeInvalid,
language_flags);
// if (valobj)
// valobj->SetAddressTypeOfChildren(eAddressTypeInvalid);
}
return valobj;
}
bool ValueObject::GetSummaryAsCString(TypeSummaryImpl *summary_ptr,
std::string &destination,
lldb::LanguageType lang) {
return GetSummaryAsCString(summary_ptr, destination,
TypeSummaryOptions().SetLanguage(lang));
}
bool ValueObject::GetSummaryAsCString(TypeSummaryImpl *summary_ptr,
std::string &destination,
const TypeSummaryOptions &options) {
destination.clear();
// ideally we would like to bail out if passing NULL, but if we do so
// we end up not providing the summary for function pointers anymore
if (/*summary_ptr == NULL ||*/ m_is_getting_summary)
return false;
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-04-16 08:01:13 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
m_is_getting_summary = true;
TypeSummaryOptions actual_options(options);
if (actual_options.GetLanguage() == lldb::eLanguageTypeUnknown)
actual_options.SetLanguage(GetPreferredDisplayLanguage());
// this is a hot path in code and we prefer to avoid setting this string all
// too often also clearing out other
// information that we might care to see in a crash log. might be useful in
// very specific situations though.
/*Host::SetCrashDescriptionWithFormat("Trying to fetch a summary for %s %s.
Summary provider's description is %s",
GetTypeName().GetCString(),
GetName().GetCString(),
summary_ptr->GetDescription().c_str());*/
if (UpdateValueIfNeeded(false) && summary_ptr) {
if (HasSyntheticValue())
m_synthetic_value->UpdateValueIfNeeded(); // the summary might depend on
// the synthetic children being
// up-to-date (e.g. ${svar%#})
summary_ptr->FormatObject(this, destination, actual_options);
}
m_is_getting_summary = false;
return !destination.empty();
}
const char *ValueObject::GetSummaryAsCString(lldb::LanguageType lang) {
if (UpdateValueIfNeeded(true) && m_summary_str.empty()) {
TypeSummaryOptions summary_options;
summary_options.SetLanguage(lang);
GetSummaryAsCString(GetSummaryFormat().get(), m_summary_str,
summary_options);
}
if (m_summary_str.empty())
return NULL;
return m_summary_str.c_str();
}
Added support for finding and global variables in the SBTarget and SBModule level in the public API. Also modified the ValueObject values to be able to display global variables without having a valid running process. The globals will read themselves from the object file section data if there is no process, and from the process if there is one. Also fixed an issue where modifications for dynamic types could cause child values of ValueObjects to not show up if the value was unable to evaluate itself (children of NULL pointer objects). llvm-svn: 134102
2011-06-30 06:09:02 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
bool ValueObject::GetSummaryAsCString(std::string &destination,
const TypeSummaryOptions &options) {
return GetSummaryAsCString(GetSummaryFormat().get(), destination, options);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
bool ValueObject::IsCStringContainer(bool check_pointer) {
CompilerType pointee_or_element_compiler_type;
const Flags type_flags(GetTypeInfo(&pointee_or_element_compiler_type));
bool is_char_arr_ptr(type_flags.AnySet(eTypeIsArray | eTypeIsPointer) &&
pointee_or_element_compiler_type.IsCharType());
if (!is_char_arr_ptr)
return false;
if (!check_pointer)
return true;
if (type_flags.Test(eTypeIsArray))
return true;
addr_t cstr_address = LLDB_INVALID_ADDRESS;
AddressType cstr_address_type = eAddressTypeInvalid;
cstr_address = GetAddressOf(true, &cstr_address_type);
return (cstr_address != LLDB_INVALID_ADDRESS);
}
size_t ValueObject::GetPointeeData(DataExtractor &data, uint32_t item_idx,
uint32_t item_count) {
CompilerType pointee_or_element_compiler_type;
const uint32_t type_info = GetTypeInfo(&pointee_or_element_compiler_type);
const bool is_pointer_type = type_info & eTypeIsPointer;
const bool is_array_type = type_info & eTypeIsArray;
if (!(is_pointer_type || is_array_type))
return 0;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (item_count == 0)
return 0;
[SBValue] Add a method GetNumChildren(uint32_t max) 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
2015-10-22 03:28:08 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ExecutionContext exe_ctx(GetExecutionContextRef());
[SBValue] Add a method GetNumChildren(uint32_t max) 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
2015-10-22 03:28:08 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
const uint64_t item_type_size = pointee_or_element_compiler_type.GetByteSize(
exe_ctx.GetBestExecutionContextScope());
const uint64_t bytes = item_count * item_type_size;
const uint64_t offset = item_idx * item_type_size;
<rdar://problem/12493007> Added a new API call to help efficiently determine if a SBValue could have children: bool SBValue::MightHaveChildren (); This is inteneded to be used bui GUI programs that need to show if a SBValue needs a disclosure triangle when displaying a hierarchical type in a tree view without having to complete the type (by calling SBValue::GetNumChildren()) as completing the type is expensive. llvm-svn: 166460
2012-10-23 09:50:10 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (item_idx == 0 && item_count == 1) // simply a deref
{
if (is_pointer_type) {
Rename Error -> Status. 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
2017-05-12 12:51:55 +08:00
Status error;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ValueObjectSP pointee_sp = Dereference(error);
if (error.Fail() || pointee_sp.get() == NULL)
return 0;
return pointee_sp->GetData(data, error);
} else {
ValueObjectSP child_sp = GetChildAtIndex(0, true);
if (child_sp.get() == NULL)
return 0;
Rename Error -> Status. 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
2017-05-12 12:51:55 +08:00
Status error;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
return child_sp->GetData(data, error);
<rdar://problem/12493007> Added a new API call to help efficiently determine if a SBValue could have children: bool SBValue::MightHaveChildren (); This is inteneded to be used bui GUI programs that need to show if a SBValue needs a disclosure triangle when displaying a hierarchical type in a tree view without having to complete the type (by calling SBValue::GetNumChildren()) as completing the type is expensive. llvm-svn: 166460
2012-10-23 09:50:10 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
return true;
} else /* (items > 1) */
{
Rename Error -> Status. 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
2017-05-12 12:51:55 +08:00
Status error;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
lldb_private::DataBufferHeap *heap_buf_ptr = NULL;
lldb::DataBufferSP data_sp(heap_buf_ptr =
new lldb_private::DataBufferHeap());
AddressType addr_type;
lldb::addr_t addr = is_pointer_type ? GetPointerValue(&addr_type)
: GetAddressOf(true, &addr_type);
switch (addr_type) {
case eAddressTypeFile: {
ModuleSP module_sp(GetModule());
if (module_sp) {
addr = addr + offset;
Address so_addr;
module_sp->ResolveFileAddress(addr, so_addr);
ExecutionContext exe_ctx(GetExecutionContextRef());
Target *target = exe_ctx.GetTargetPtr();
if (target) {
heap_buf_ptr->SetByteSize(bytes);
size_t bytes_read = target->ReadMemory(
so_addr, false, heap_buf_ptr->GetBytes(), bytes, error);
if (error.Success()) {
data.SetData(data_sp);
return bytes_read;
}
}
}
} break;
case eAddressTypeLoad: {
ExecutionContext exe_ctx(GetExecutionContextRef());
Process *process = exe_ctx.GetProcessPtr();
if (process) {
heap_buf_ptr->SetByteSize(bytes);
size_t bytes_read = process->ReadMemory(
addr + offset, heap_buf_ptr->GetBytes(), bytes, error);
if (error.Success() || bytes_read > 0) {
data.SetData(data_sp);
return bytes_read;
}
}
} break;
case eAddressTypeHost: {
const uint64_t max_bytes =
GetCompilerType().GetByteSize(exe_ctx.GetBestExecutionContextScope());
if (max_bytes > offset) {
size_t bytes_read = std::min<uint64_t>(max_bytes - offset, bytes);
addr = m_value.GetScalar().ULongLong(LLDB_INVALID_ADDRESS);
if (addr == 0 || addr == LLDB_INVALID_ADDRESS)
break;
heap_buf_ptr->CopyData((uint8_t *)(addr + offset), bytes_read);
data.SetData(data_sp);
return bytes_read;
}
} break;
case eAddressTypeInvalid:
break;
}
}
return 0;
}
Rename Error -> Status. 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
2017-05-12 12:51:55 +08:00
uint64_t ValueObject::GetData(DataExtractor &data, Status &error) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
UpdateValueIfNeeded(false);
ExecutionContext exe_ctx(GetExecutionContextRef());
error = m_value.GetValueAsData(&exe_ctx, data, 0, GetModule().get());
if (error.Fail()) {
if (m_data.GetByteSize()) {
data = m_data;
error.Clear();
return data.GetByteSize();
} else {
return 0;
}
}
data.SetAddressByteSize(m_data.GetAddressByteSize());
data.SetByteOrder(m_data.GetByteOrder());
return data.GetByteSize();
}
Rename Error -> Status. 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
2017-05-12 12:51:55 +08:00
bool ValueObject::SetData(DataExtractor &data, Status &error) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
error.Clear();
// Make sure our value is up to date first so that our location and location
// type is valid.
if (!UpdateValueIfNeeded(false)) {
error.SetErrorString("unable to read value");
return false;
}
uint64_t count = 0;
const Encoding encoding = GetCompilerType().GetEncoding(count);
const size_t byte_size = GetByteSize();
Value::ValueType value_type = m_value.GetValueType();
switch (value_type) {
case Value::eValueTypeScalar: {
Rename Error -> Status. 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
2017-05-12 12:51:55 +08:00
Status set_error =
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
m_value.GetScalar().SetValueFromData(data, encoding, byte_size);
if (!set_error.Success()) {
error.SetErrorStringWithFormat("unable to set scalar value: %s",
set_error.AsCString());
return false;
<rdar://problem/12493007> Added a new API call to help efficiently determine if a SBValue could have children: bool SBValue::MightHaveChildren (); This is inteneded to be used bui GUI programs that need to show if a SBValue needs a disclosure triangle when displaying a hierarchical type in a tree view without having to complete the type (by calling SBValue::GetNumChildren()) as completing the type is expensive. llvm-svn: 166460
2012-10-23 09:50:10 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
} break;
case Value::eValueTypeLoadAddress: {
// If it is a load address, then the scalar value is the storage location
// of the data, and we have to shove this value down to that load location.
ExecutionContext exe_ctx(GetExecutionContextRef());
Process *process = exe_ctx.GetProcessPtr();
if (process) {
addr_t target_addr = m_value.GetScalar().ULongLong(LLDB_INVALID_ADDRESS);
size_t bytes_written = process->WriteMemory(
target_addr, data.GetDataStart(), byte_size, error);
if (!error.Success())
return false;
if (bytes_written != byte_size) {
error.SetErrorString("unable to write value to memory");
return false;
}
}
} break;
case Value::eValueTypeHostAddress: {
// If it is a host address, then we stuff the scalar as a DataBuffer into
// the Value's data.
DataBufferSP buffer_sp(new DataBufferHeap(byte_size, 0));
m_data.SetData(buffer_sp, 0);
data.CopyByteOrderedData(0, byte_size,
const_cast<uint8_t *>(m_data.GetDataStart()),
byte_size, m_data.GetByteOrder());
m_value.GetScalar() = (uintptr_t)m_data.GetDataStart();
} break;
case Value::eValueTypeFileAddress:
case Value::eValueTypeVector:
break;
}
// If we have reached this point, then we have successfully changed the value.
SetNeedsUpdate();
return true;
}
static bool CopyStringDataToBufferSP(const StreamString &source,
lldb::DataBufferSP &destination) {
destination.reset(new DataBufferHeap(source.GetSize() + 1, 0));
Don't allow direct access to StreamString's internal buffer. 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
2016-11-17 05:15:24 +08:00
memcpy(destination->GetBytes(), source.GetString().data(), source.GetSize());
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
return true;
}
std::pair<size_t, bool>
Rename Error -> Status. 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
2017-05-12 12:51:55 +08:00
ValueObject::ReadPointedString(lldb::DataBufferSP &buffer_sp, Status &error,
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
uint32_t max_length, bool honor_array,
Format item_format) {
bool was_capped = false;
StreamString s;
ExecutionContext exe_ctx(GetExecutionContextRef());
Target *target = exe_ctx.GetTargetPtr();
if (!target) {
s << "<no target to read from>";
error.SetErrorString("no target to read from");
CopyStringDataToBufferSP(s, buffer_sp);
return {0, was_capped};
}
<rdar://problem/12493007> Added a new API call to help efficiently determine if a SBValue could have children: bool SBValue::MightHaveChildren (); This is inteneded to be used bui GUI programs that need to show if a SBValue needs a disclosure triangle when displaying a hierarchical type in a tree view without having to complete the type (by calling SBValue::GetNumChildren()) as completing the type is expensive. llvm-svn: 166460
2012-10-23 09:50:10 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (max_length == 0)
max_length = target->GetMaximumSizeOfStringSummary();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
size_t bytes_read = 0;
size_t total_bytes_read = 0;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
CompilerType compiler_type = GetCompilerType();
CompilerType elem_or_pointee_compiler_type;
const Flags type_flags(GetTypeInfo(&elem_or_pointee_compiler_type));
if (type_flags.AnySet(eTypeIsArray | eTypeIsPointer) &&
elem_or_pointee_compiler_type.IsCharType()) {
addr_t cstr_address = LLDB_INVALID_ADDRESS;
AddressType cstr_address_type = eAddressTypeInvalid;
Added support for finding and global variables in the SBTarget and SBModule level in the public API. Also modified the ValueObject values to be able to display global variables without having a valid running process. The globals will read themselves from the object file section data if there is no process, and from the process if there is one. Also fixed an issue where modifications for dynamic types could cause child values of ValueObjects to not show up if the value was unable to evaluate itself (children of NULL pointer objects). llvm-svn: 134102
2011-06-30 06:09:02 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
size_t cstr_len = 0;
bool capped_data = false;
const bool is_array = type_flags.Test(eTypeIsArray);
if (is_array) {
// We have an array
uint64_t array_size = 0;
if (compiler_type.IsArrayType(NULL, &array_size, NULL)) {
cstr_len = array_size;
if (cstr_len > max_length) {
capped_data = true;
cstr_len = max_length;
}
}
cstr_address = GetAddressOf(true, &cstr_address_type);
} else {
// We have a pointer
cstr_address = GetPointerValue(&cstr_address_type);
}
if (cstr_address == 0 || cstr_address == LLDB_INVALID_ADDRESS) {
if (cstr_address_type == eAddressTypeHost && is_array) {
const char *cstr = GetDataExtractor().PeekCStr(0);
if (cstr == nullptr) {
s << "<invalid address>";
error.SetErrorString("invalid address");
CopyStringDataToBufferSP(s, buffer_sp);
return {0, was_capped};
}
buffer_sp.reset(new DataBufferHeap(cstr_len, 0));
memcpy(buffer_sp->GetBytes(), cstr, cstr_len);
return {cstr_len, was_capped};
} else {
s << "<invalid address>";
error.SetErrorString("invalid address");
CopyStringDataToBufferSP(s, buffer_sp);
return {0, was_capped};
}
}
Address cstr_so_addr(cstr_address);
DataExtractor data;
if (cstr_len > 0 && honor_array) {
// I am using GetPointeeData() here to abstract the fact that some
// ValueObjects are actually frozen pointers in the host
// but the pointed-to data lives in the debuggee, and GetPointeeData()
// automatically takes care of this
GetPointeeData(data, 0, cstr_len);
if ((bytes_read = data.GetByteSize()) > 0) {
total_bytes_read = bytes_read;
for (size_t offset = 0; offset < bytes_read; offset++)
s.Printf("%c", *data.PeekData(offset, 1));
if (capped_data)
was_capped = true;
}
} else {
cstr_len = max_length;
const size_t k_max_buf_size = 64;
size_t offset = 0;
int cstr_len_displayed = -1;
bool capped_cstr = false;
// I am using GetPointeeData() here to abstract the fact that some
// ValueObjects are actually frozen pointers in the host
// but the pointed-to data lives in the debuggee, and GetPointeeData()
// automatically takes care of this
while ((bytes_read = GetPointeeData(data, offset, k_max_buf_size)) > 0) {
total_bytes_read += bytes_read;
const char *cstr = data.PeekCStr(0);
size_t len = strnlen(cstr, k_max_buf_size);
if (cstr_len_displayed < 0)
cstr_len_displayed = len;
if (len == 0)
break;
cstr_len_displayed += len;
if (len > bytes_read)
len = bytes_read;
if (len > cstr_len)
len = cstr_len;
for (size_t offset = 0; offset < bytes_read; offset++)
s.Printf("%c", *data.PeekData(offset, 1));
if (len < k_max_buf_size)
break;
if (len >= cstr_len) {
capped_cstr = true;
break;
}
cstr_len -= len;
offset += len;
}
if (cstr_len_displayed >= 0) {
if (capped_cstr)
was_capped = true;
}
}
} else {
error.SetErrorString("not a string object");
s << "<not a string object>";
}
CopyStringDataToBufferSP(s, buffer_sp);
return {total_bytes_read, was_capped};
}
std::pair<TypeValidatorResult, std::string> ValueObject::GetValidationStatus() {
if (!UpdateValueIfNeeded(true))
return {TypeValidatorResult::Success,
""}; // not the validator's job to discuss update problems
if (m_validation_result.hasValue())
return m_validation_result.getValue();
if (!m_type_validator_sp)
return {TypeValidatorResult::Success, ""}; // no validator no failure
auto outcome = m_type_validator_sp->FormatObject(this);
return (m_validation_result = {outcome.m_result, outcome.m_message})
.getValue();
}
const char *ValueObject::GetObjectDescription() {
if (!UpdateValueIfNeeded(true))
return NULL;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (!m_object_desc_str.empty())
return m_object_desc_str.c_str();
Introduce the notion of "type summary options" as flags that can be passed 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
2014-11-07 05:23:20 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ExecutionContext exe_ctx(GetExecutionContextRef());
Process *process = exe_ctx.GetProcessPtr();
if (process == NULL)
return NULL;
StreamString s;
LanguageType language = GetObjectRuntimeLanguage();
LanguageRuntime *runtime = process->GetLanguageRuntime(language);
if (runtime == NULL) {
// Aw, hell, if the things a pointer, or even just an integer, let's try
// ObjC anyway...
CompilerType compiler_type = GetCompilerType();
if (compiler_type) {
bool is_signed;
if (compiler_type.IsIntegerType(is_signed) ||
compiler_type.IsPointerType()) {
runtime = process->GetLanguageRuntime(eLanguageTypeObjC);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
if (runtime && runtime->GetObjectDescription(s, *this)) {
Don't allow direct access to StreamString's internal buffer. 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
2016-11-17 05:15:24 +08:00
m_object_desc_str.append(s.GetString());
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
if (m_object_desc_str.empty())
return NULL;
else
return m_object_desc_str.c_str();
1) solving a bug where, after Jim's fixes to stack frames, synthetic children were not recalculated when necessary, causing them to get out of sync with live data 2) providing an updated list of tagged pointers values for the objc_runtime module - hopefully this one is final 3) changing ValueObject::DumpValueObject to use an Options class instead of providing a bulky list of parameters to pass around this change had been laid out previously, but some clients of DumpValueObject() were still using the old prototype and some arguments were treated in a special way and passed in directly instead of through the Options class 4) providing new GetSummaryAsCString() and GetValueAsCString() calls in ValueObject that are passed a formatter object and a destination string and fill the string by formatting themselves using the formatter argument instead of the default for the current ValueObject 5) removing the option to have formats and summaries stick to a variable for the current stoppoint after some debate, we are going with non-sticky: if you say frame variable --format hex foo, the hex format will only be applied to the current command execution and not stick when redisplaying foo the other option would be full stickiness, which means that foo would be formatted as hex for its whole lifetime we are open to suggestions on what feels "natural" in this regard llvm-svn: 151801
2012-03-01 12:24:26 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
bool ValueObject::GetValueAsCString(const lldb_private::TypeFormatImpl &format,
std::string &destination) {
if (UpdateValueIfNeeded(false))
return format.FormatObject(this, destination);
else
return false;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
bool ValueObject::GetValueAsCString(lldb::Format format,
std::string &destination) {
return GetValueAsCString(TypeFormatImpl_Format(format), destination);
}
const char *ValueObject::GetValueAsCString() {
if (UpdateValueIfNeeded(true)) {
lldb::TypeFormatImplSP format_sp;
lldb::Format my_format = GetFormat();
if (my_format == lldb::eFormatDefault) {
if (m_type_format_sp)
format_sp = m_type_format_sp;
else {
if (m_is_bitfield_for_scalar)
my_format = eFormatUnsigned;
else {
if (m_value.GetContextType() == Value::eContextTypeRegisterInfo) {
const RegisterInfo *reg_info = m_value.GetRegisterInfo();
if (reg_info)
my_format = reg_info->format;
} else {
my_format = GetValue().GetCompilerType().GetFormat();
}
}
}
}
if (my_format != m_last_format || m_value_str.empty()) {
m_last_format = my_format;
if (!format_sp)
format_sp.reset(new TypeFormatImpl_Format(my_format));
if (GetValueAsCString(*format_sp.get(), m_value_str)) {
if (!m_value_did_change && m_old_value_valid) {
// The value was gotten successfully, so we consider the
// value as changed if the value string differs
SetValueDidChange(m_old_value_str != m_value_str);
}
}
}
}
if (m_value_str.empty())
return NULL;
return m_value_str.c_str();
Shuffle APIs around a little bit, so that if you pass custom summary 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
2014-11-19 07:36:25 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
// if > 8bytes, 0 is returned. this method should mostly be used
// to read address values out of pointers
uint64_t ValueObject::GetValueAsUnsigned(uint64_t fail_value, bool *success) {
// If our byte size is zero this is an aggregate type that has children
if (CanProvideValue()) {
Scalar scalar;
if (ResolveValue(scalar)) {
if (success)
*success = true;
return scalar.ULongLong(fail_value);
}
// fallthrough, otherwise...
}
if (success)
*success = false;
return fail_value;
}
int64_t ValueObject::GetValueAsSigned(int64_t fail_value, bool *success) {
// If our byte size is zero this is an aggregate type that has children
if (CanProvideValue()) {
Scalar scalar;
if (ResolveValue(scalar)) {
if (success)
*success = true;
return scalar.SLongLong(fail_value);
}
// fallthrough, otherwise...
}
if (success)
*success = false;
return fail_value;
}
// if any more "special cases" are added to
// ValueObject::DumpPrintableRepresentation() please keep
// this call up to date by returning true for your new special cases. We will
// eventually move
// to checking this call result before trying to display special cases
bool ValueObject::HasSpecialPrintableRepresentation(
ValueObjectRepresentationStyle val_obj_display, Format custom_format) {
Flags flags(GetTypeInfo());
if (flags.AnySet(eTypeIsArray | eTypeIsPointer) &&
val_obj_display == ValueObject::eValueObjectRepresentationStyleValue) {
if (IsCStringContainer(true) &&
(custom_format == eFormatCString || custom_format == eFormatCharArray ||
custom_format == eFormatChar || custom_format == eFormatVectorOfChar))
return true;
if (flags.Test(eTypeIsArray)) {
if ((custom_format == eFormatBytes) ||
(custom_format == eFormatBytesWithASCII))
named summaries: - a new --name option for "type summary add" lets you give a name to a summary - a new --summary option for "frame variable" lets you bind a named summary to one or more variables ${var%s} now works for printing the value of 0-terminated CStrings type format test case now tests for cascading - this is disabled on GCC because GCC may end up stripping typedef chains, basically breaking cascading new design for the FormatNavigator class new template class CleanUp2 meant to support cleanup routines with 1 additional parameter beyond resource handle llvm-svn: 134943
2011-07-12 08:18:11 +08:00
return true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if ((custom_format == eFormatVectorOfChar) ||
(custom_format == eFormatVectorOfFloat32) ||
(custom_format == eFormatVectorOfFloat64) ||
(custom_format == eFormatVectorOfSInt16) ||
(custom_format == eFormatVectorOfSInt32) ||
(custom_format == eFormatVectorOfSInt64) ||
(custom_format == eFormatVectorOfSInt8) ||
(custom_format == eFormatVectorOfUInt128) ||
(custom_format == eFormatVectorOfUInt16) ||
(custom_format == eFormatVectorOfUInt32) ||
(custom_format == eFormatVectorOfUInt64) ||
(custom_format == eFormatVectorOfUInt8))
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-07 03:20:51 +08:00
return true;
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
return false;
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-07 03:20:51 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
bool ValueObject::DumpPrintableRepresentation(
Stream &s, ValueObjectRepresentationStyle val_obj_display,
Format custom_format, PrintableRepresentationSpecialCases special,
bool do_dump_error) {
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-07 03:20:51 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Flags flags(GetTypeInfo());
Simplify the PrintableRepresentationSpecialCases code; we never used the ePrintableRepresentationSpecialCasesOnly value and with enum classes the names doesn't need to be that long llvm-svn: 286176
2016-11-08 07:32:20 +08:00
bool allow_special =
(special == ValueObject::PrintableRepresentationSpecialCases::eAllow);
const bool only_special = false;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (allow_special) {
if (flags.AnySet(eTypeIsArray | eTypeIsPointer) &&
val_obj_display == ValueObject::eValueObjectRepresentationStyleValue) {
// when being asked to get a printable display an array or pointer type
// directly,
// try to "do the right thing"
if (IsCStringContainer(true) &&
(custom_format == eFormatCString ||
custom_format == eFormatCharArray || custom_format == eFormatChar ||
custom_format ==
eFormatVectorOfChar)) // print char[] & char* directly
{
Rename Error -> Status. 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
2017-05-12 12:51:55 +08:00
Status error;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
lldb::DataBufferSP buffer_sp;
std::pair<size_t, bool> read_string = ReadPointedString(
buffer_sp, error, 0, (custom_format == eFormatVectorOfChar) ||
(custom_format == eFormatCharArray));
lldb_private::formatters::StringPrinter::
ReadBufferAndDumpToStreamOptions options(*this);
options.SetData(DataExtractor(
buffer_sp, lldb::eByteOrderInvalid,
8)); // none of this matters for a string - pass some defaults
options.SetStream(&s);
options.SetPrefixToken(0);
options.SetQuote('"');
options.SetSourceSize(buffer_sp->GetByteSize());
options.SetIsTruncated(read_string.second);
formatters::StringPrinter::ReadBufferAndDumpToStream<
lldb_private::formatters::StringPrinter::StringElementType::ASCII>(
options);
return !error.Fail();
}
if (custom_format == eFormatEnum)
Added a SetData() method to ValueObject. This lets a ValueObject's contents be set from raw data. This has certain limitations (notably, registers can only be set to data that is as large as the register) but will be useful for the new Materializer. I also exposed this interface through SBValue. I have added a testcase that exercises various special cases of SBValue::SetData(). llvm-svn: 179437
2013-04-13 09:21:23 +08:00
return false;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
// this only works for arrays, because I have no way to know when
// the pointed memory ends, and no special \0 end of data marker
if (flags.Test(eTypeIsArray)) {
if ((custom_format == eFormatBytes) ||
(custom_format == eFormatBytesWithASCII)) {
const size_t count = GetNumChildren();
s << '[';
for (size_t low = 0; low < count; low++) {
if (low)
s << ',';
ValueObjectSP child = GetChildAtIndex(low, true);
if (!child.get()) {
s << "<invalid child>";
continue;
Added a SetData() method to ValueObject. This lets a ValueObject's contents be set from raw data. This has certain limitations (notably, registers can only be set to data that is as large as the register) but will be useful for the new Materializer. I also exposed this interface through SBValue. I have added a testcase that exercises various special cases of SBValue::SetData(). llvm-svn: 179437
2013-04-13 09:21:23 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
child->DumpPrintableRepresentation(
s, ValueObject::eValueObjectRepresentationStyleValue,
custom_format);
}
s << ']';
return true;
}
if ((custom_format == eFormatVectorOfChar) ||
(custom_format == eFormatVectorOfFloat32) ||
(custom_format == eFormatVectorOfFloat64) ||
(custom_format == eFormatVectorOfSInt16) ||
(custom_format == eFormatVectorOfSInt32) ||
(custom_format == eFormatVectorOfSInt64) ||
(custom_format == eFormatVectorOfSInt8) ||
(custom_format == eFormatVectorOfUInt128) ||
(custom_format == eFormatVectorOfUInt16) ||
(custom_format == eFormatVectorOfUInt32) ||
(custom_format == eFormatVectorOfUInt64) ||
(custom_format == eFormatVectorOfUInt8)) // arrays of bytes, bytes
// with ASCII or any vector
// format should be printed
// directly
{
const size_t count = GetNumChildren();
Format format = FormatManager::GetSingleItemFormat(custom_format);
s << '[';
for (size_t low = 0; low < count; low++) {
if (low)
s << ',';
ValueObjectSP child = GetChildAtIndex(low, true);
if (!child.get()) {
s << "<invalid child>";
continue;
Added a SetData() method to ValueObject. This lets a ValueObject's contents be set from raw data. This has certain limitations (notably, registers can only be set to data that is as large as the register) but will be useful for the new Materializer. I also exposed this interface through SBValue. I have added a testcase that exercises various special cases of SBValue::SetData(). llvm-svn: 179437
2013-04-13 09:21:23 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
child->DumpPrintableRepresentation(
s, ValueObject::eValueObjectRepresentationStyleValue, format);
}
s << ']';
return true;
}
}
if ((custom_format == eFormatBoolean) ||
(custom_format == eFormatBinary) || (custom_format == eFormatChar) ||
(custom_format == eFormatCharPrintable) ||
(custom_format == eFormatComplexFloat) ||
(custom_format == eFormatDecimal) || (custom_format == eFormatHex) ||
(custom_format == eFormatHexUppercase) ||
(custom_format == eFormatFloat) || (custom_format == eFormatOctal) ||
(custom_format == eFormatOSType) ||
(custom_format == eFormatUnicode16) ||
(custom_format == eFormatUnicode32) ||
(custom_format == eFormatUnsigned) ||
(custom_format == eFormatPointer) ||
(custom_format == eFormatComplexInteger) ||
(custom_format == eFormatComplex) ||
(custom_format == eFormatDefault)) // use the [] operator
1) solving a bug where, after Jim's fixes to stack frames, synthetic children were not recalculated when necessary, causing them to get out of sync with live data 2) providing an updated list of tagged pointers values for the objc_runtime module - hopefully this one is final 3) changing ValueObject::DumpValueObject to use an Options class instead of providing a bulky list of parameters to pass around this change had been laid out previously, but some clients of DumpValueObject() were still using the old prototype and some arguments were treated in a special way and passed in directly instead of through the Options class 4) providing new GetSummaryAsCString() and GetValueAsCString() calls in ValueObject that are passed a formatter object and a destination string and fill the string by formatting themselves using the formatter argument instead of the default for the current ValueObject 5) removing the option to have formats and summaries stick to a variable for the current stoppoint after some debate, we are going with non-sticky: if you say frame variable --format hex foo, the hex format will only be applied to the current command execution and not stick when redisplaying foo the other option would be full stickiness, which means that foo would be formatted as hex for its whole lifetime we are open to suggestions on what feels "natural" in this regard llvm-svn: 151801
2012-03-01 12:24:26 +08:00
return false;
Fixed a bug where a variable could not be formatted in a summary if its datatype already had a custom format Fixed a bug where Objective-C variables coming out of the expression parser could crash the Python synthetic providers: - expression parser output has a "frozen data" component, which is a byte-exact copy of the value (in host memory), if trying to read into memory based on the host address, LLDB would crash. we are now passing the correct (target) pointer to the Python code Objective-C "id" variables are now formatted according to their dynamic type, if the -d option to frame variable is used: - Code based on the Objective-C 2.0 runtime is used to obtain this information without running code on the target llvm-svn: 136695
2011-08-03 01:27:39 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
rdar://problem/11597911 Fix confusing error message about "expression did not evaluate to an address" when doing 'watchpoint set expression". Instead of using 0 as the fail_value when invoking ValueObject::GetValueAsUnsigned(), modify the API to take an addition bool pointer (defaults to NULL) to indicate success/failure of value conversion. llvm-svn: 158016
2012-06-06 03:37:43 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (only_special)
- Now using ${var} as the summary for an aggregate type will produce "name-of-type @ object-location" instead of giving an error e.g. you may get "foo_class @ 0x123456" when typing "type summary add -f ${var} foo_class" - Added a new special formatting token %T for summaries. This shows the type of the object. Using it, the new "type @ location" summary could be manually generated by writing ${var%T} @ ${var%L} - Bits and pieces required to support "frame variable array[n-m]" The feature is not enabled yet because some additional design and support code is required, but the basics are getting there - Fixed a potential issue where a ValueObjectSyntheticFilter was not holding on to its SyntheticChildrenSP Because of the way VOSF are being built now, this has never been an actual issue, but it is still sensible for a VOSF to hold on to the SyntheticChildrenSP as well as to its FrontEnd llvm-svn: 138080
2011-08-20 05:13:46 +08:00
return false;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
bool var_success = false;
{
Don't allow direct access to StreamString's internal buffer. 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
2016-11-17 05:15:24 +08:00
llvm::StringRef str;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
// this is a local stream that we are using to ensure that the data pointed
Don't allow direct access to StreamString's internal buffer. 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
2016-11-17 05:15:24 +08:00
// to by cstr survives long enough for us to copy it to its destination - it
// is necessary to have this temporary storage area for cases where our
// desired output is not backed by some other longer-term storage
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
StreamString strm;
if (custom_format != eFormatInvalid)
SetFormat(custom_format);
switch (val_obj_display) {
case eValueObjectRepresentationStyleValue:
Don't allow direct access to StreamString's internal buffer. 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
2016-11-17 05:15:24 +08:00
str = GetValueAsCString();
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
case eValueObjectRepresentationStyleSummary:
Don't allow direct access to StreamString's internal buffer. 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
2016-11-17 05:15:24 +08:00
str = GetSummaryAsCString();
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
case eValueObjectRepresentationStyleLanguageSpecific:
Don't allow direct access to StreamString's internal buffer. 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
2016-11-17 05:15:24 +08:00
str = GetObjectDescription();
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
case eValueObjectRepresentationStyleLocation:
Don't allow direct access to StreamString's internal buffer. 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
2016-11-17 05:15:24 +08:00
str = GetLocationAsCString();
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
case eValueObjectRepresentationStyleChildrenCount:
strm.Printf("%" PRIu64 "", (uint64_t)GetNumChildren());
Don't allow direct access to StreamString's internal buffer. 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
2016-11-17 05:15:24 +08:00
str = strm.GetString();
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
case eValueObjectRepresentationStyleType:
Don't allow direct access to StreamString's internal buffer. 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
2016-11-17 05:15:24 +08:00
str = GetTypeName().GetStringRef();
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
case eValueObjectRepresentationStyleName:
Don't allow direct access to StreamString's internal buffer. 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
2016-11-17 05:15:24 +08:00
str = GetName().GetStringRef();
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
case eValueObjectRepresentationStyleExpressionPath:
GetExpressionPath(strm, false);
Don't allow direct access to StreamString's internal buffer. 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
2016-11-17 05:15:24 +08:00
str = strm.GetString();
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
}
Don't allow direct access to StreamString's internal buffer. 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
2016-11-17 05:15:24 +08:00
if (str.empty()) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (val_obj_display == eValueObjectRepresentationStyleValue)
Don't allow direct access to StreamString's internal buffer. 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
2016-11-17 05:15:24 +08:00
str = GetSummaryAsCString();
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
else if (val_obj_display == eValueObjectRepresentationStyleSummary) {
if (!CanProvideValue()) {
strm.Printf("%s @ %s", GetTypeName().AsCString(),
GetLocationAsCString());
Don't allow direct access to StreamString's internal buffer. 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
2016-11-17 05:15:24 +08:00
str = strm.GetString();
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
} else
Don't allow direct access to StreamString's internal buffer. 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
2016-11-17 05:15:24 +08:00
str = GetValueAsCString();
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
}
Don't allow direct access to StreamString's internal buffer. 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
2016-11-17 05:15:24 +08:00
if (!str.empty())
s << str;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
else {
if (m_error.Fail()) {
if (do_dump_error)
s.Printf("<%s>", m_error.AsCString());
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-20 06:58:49 +08:00
else
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
return false;
} else if (val_obj_display == eValueObjectRepresentationStyleSummary)
s.PutCString("<no summary available>");
else if (val_obj_display == eValueObjectRepresentationStyleValue)
s.PutCString("<no value available>");
else if (val_obj_display ==
eValueObjectRepresentationStyleLanguageSpecific)
s.PutCString("<not a valid Objective-C object>"); // edit this if we
// have other runtimes
// that support a
// description
else
s.PutCString("<no printable representation>");
}
// we should only return false here if we could not do *anything*
// even if we have an error message as output, that's a success
// from our callers' perspective, so return true
var_success = true;
if (custom_format != eFormatInvalid)
SetFormat(eFormatDefault);
}
return var_success;
}
addr_t ValueObject::GetAddressOf(bool scalar_is_load_address,
AddressType *address_type) {
// Can't take address of a bitfield
if (IsBitfield())
return LLDB_INVALID_ADDRESS;
several improvements to "type summary": - type names can now be regular expressions (exact matching is done first, and is faster) - integral (and floating) types can be printed as bitfields, i.e. ${var[low-high]} will extract bits low thru high of the value and print them - array subscripts are supported, both for arrays and for pointers. the syntax is ${*var[low-high]}, or ${*var[]} to print the whole array (the latter only works for statically sized arrays) - summary is now printed by default when a summary string references a variable. if that variable's type has no summary, value is printed instead. to force value, you can use %V as a format specifier - basic support for ObjectiveC: - ObjectiveC inheritance chains are now walked through - %@ can be specified as a summary format, to print the ObjectiveC runtime description for an object - some bug fixes llvm-svn: 134293
2011-07-02 08:25:22 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (!UpdateValueIfNeeded(false))
return LLDB_INVALID_ADDRESS;
Updated the lldb_private::Flags class to have better method names and made all of the calls inlined in the header file for better performance. Fixed the summary for C string types (array of chars (with any combo if modifiers), and pointers to chars) work in all cases. Fixed an issue where a forward declaration to a clang type could cause itself to resolve itself more than once if, during the resolving of the type itself it caused something to try and resolve itself again. We now remove the clang type from the forward declaration map in the DWARF parser when we start to resolve it and avoid this additional call. This should stop any duplicate members from appearing and throwing all the alignment of structs, unions and classes. llvm-svn: 117437
2010-10-27 11:32:59 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
switch (m_value.GetValueType()) {
case Value::eValueTypeScalar:
case Value::eValueTypeVector:
if (scalar_is_load_address) {
if (address_type)
*address_type = eAddressTypeLoad;
return m_value.GetScalar().ULongLong(LLDB_INVALID_ADDRESS);
Updated the lldb_private::Flags class to have better method names and made all of the calls inlined in the header file for better performance. Fixed the summary for C string types (array of chars (with any combo if modifiers), and pointers to chars) work in all cases. Fixed an issue where a forward declaration to a clang type could cause itself to resolve itself more than once if, during the resolving of the type itself it caused something to try and resolve itself again. We now remove the clang type from the forward declaration map in the DWARF parser when we start to resolve it and avoid this additional call. This should stop any duplicate members from appearing and throwing all the alignment of structs, unions and classes. llvm-svn: 117437
2010-10-27 11:32:59 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
case Value::eValueTypeLoadAddress:
case Value::eValueTypeFileAddress: {
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-07 03:20:51 +08:00
if (address_type)
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
*address_type = m_value.GetValueAddressType();
return m_value.GetScalar().ULongLong(LLDB_INVALID_ADDRESS);
} break;
case Value::eValueTypeHostAddress: {
if (address_type)
*address_type = m_value.GetValueAddressType();
Updated the lldb_private::Flags class to have better method names and made all of the calls inlined in the header file for better performance. Fixed the summary for C string types (array of chars (with any combo if modifiers), and pointers to chars) work in all cases. Fixed an issue where a forward declaration to a clang type could cause itself to resolve itself more than once if, during the resolving of the type itself it caused something to try and resolve itself again. We now remove the clang type from the forward declaration map in the DWARF parser when we start to resolve it and avoid this additional call. This should stop any duplicate members from appearing and throwing all the alignment of structs, unions and classes. llvm-svn: 117437
2010-10-27 11:32:59 +08:00
return LLDB_INVALID_ADDRESS;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
} break;
}
if (address_type)
*address_type = eAddressTypeInvalid;
return LLDB_INVALID_ADDRESS;
Updated the lldb_private::Flags class to have better method names and made all of the calls inlined in the header file for better performance. Fixed the summary for C string types (array of chars (with any combo if modifiers), and pointers to chars) work in all cases. Fixed an issue where a forward declaration to a clang type could cause itself to resolve itself more than once if, during the resolving of the type itself it caused something to try and resolve itself again. We now remove the clang type from the forward declaration map in the DWARF parser when we start to resolve it and avoid this additional call. This should stop any duplicate members from appearing and throwing all the alignment of structs, unions and classes. llvm-svn: 117437
2010-10-27 11:32:59 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
addr_t ValueObject::GetPointerValue(AddressType *address_type) {
addr_t address = LLDB_INVALID_ADDRESS;
if (address_type)
*address_type = eAddressTypeInvalid;
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (!UpdateValueIfNeeded(false))
Added the summary values for function pointers so we can show where they point to. llvm-svn: 113735
2010-09-13 11:32:57 +08:00
return address;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
switch (m_value.GetValueType()) {
case Value::eValueTypeScalar:
case Value::eValueTypeVector:
address = m_value.GetScalar().ULongLong(LLDB_INVALID_ADDRESS);
break;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
case Value::eValueTypeHostAddress:
case Value::eValueTypeLoadAddress:
case Value::eValueTypeFileAddress: {
lldb::offset_t data_offset = 0;
address = m_data.GetPointer(&data_offset);
} break;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (address_type)
*address_type = GetAddressTypeOfChildren();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
return address;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Rename Error -> Status. 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
2017-05-12 12:51:55 +08:00
bool ValueObject::SetValueFromCString(const char *value_str, Status &error) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
error.Clear();
// Make sure our value is up to date first so that our location and location
// type is valid.
if (!UpdateValueIfNeeded(false)) {
error.SetErrorString("unable to read value");
Convert all python objects in our API to use overload the __str__ method instead of the __repr__. __repr__ is a function that should return an expression that can be used to recreate an python object and we were using it to just return a human readable string. Fixed a crasher when using the new implementation of SBValue::Cast(SBType). Thread hardened lldb::SBValue and lldb::SBWatchpoint and did other general improvements to the API. Fixed a crasher in lldb::SBValue::GetChildMemberWithName() where we didn't correctly handle not having a target. llvm-svn: 149743
2012-02-04 10:27:34 +08:00
return false;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
uint64_t count = 0;
const Encoding encoding = GetCompilerType().GetEncoding(count);
const size_t byte_size = GetByteSize();
Value::ValueType value_type = m_value.GetValueType();
if (value_type == Value::eValueTypeScalar) {
// If the value is already a scalar, then let the scalar change itself:
m_value.GetScalar().SetValueFromCString(value_str, encoding, byte_size);
} else if (byte_size <= 16) {
// If the value fits in a scalar, then make a new scalar and again let the
// scalar code do the conversion, then figure out where to put the new
// value.
Scalar new_scalar;
error = new_scalar.SetValueFromCString(value_str, encoding, byte_size);
if (error.Success()) {
switch (value_type) {
case Value::eValueTypeLoadAddress: {
// If it is a load address, then the scalar value is the storage
// location
// of the data, and we have to shove this value down to that load
// location.
ExecutionContext exe_ctx(GetExecutionContextRef());
Process *process = exe_ctx.GetProcessPtr();
if (process) {
addr_t target_addr =
m_value.GetScalar().ULongLong(LLDB_INVALID_ADDRESS);
size_t bytes_written = process->WriteScalarToMemory(
target_addr, new_scalar, byte_size, error);
if (!error.Success())
return false;
if (bytes_written != byte_size) {
error.SetErrorString("unable to write value to memory");
return false;
}
}
} break;
case Value::eValueTypeHostAddress: {
// If it is a host address, then we stuff the scalar as a DataBuffer
// into the Value's data.
DataExtractor new_data;
new_data.SetByteOrder(m_data.GetByteOrder());
DataBufferSP buffer_sp(new DataBufferHeap(byte_size, 0));
m_data.SetData(buffer_sp, 0);
bool success = new_scalar.GetData(new_data);
if (success) {
new_data.CopyByteOrderedData(
0, byte_size, const_cast<uint8_t *>(m_data.GetDataStart()),
byte_size, m_data.GetByteOrder());
}
m_value.GetScalar() = (uintptr_t)m_data.GetDataStart();
} break;
case Value::eValueTypeFileAddress:
case Value::eValueTypeScalar:
case Value::eValueTypeVector:
break;
}
} else {
return false;
}
} else {
// We don't support setting things bigger than a scalar at present.
error.SetErrorString("unable to write aggregate data type");
return false;
}
Convert all python objects in our API to use overload the __str__ method instead of the __repr__. __repr__ is a function that should return an expression that can be used to recreate an python object and we were using it to just return a human readable string. Fixed a crasher when using the new implementation of SBValue::Cast(SBType). Thread hardened lldb::SBValue and lldb::SBWatchpoint and did other general improvements to the API. Fixed a crasher in lldb::SBValue::GetChildMemberWithName() where we didn't correctly handle not having a target. llvm-svn: 149743
2012-02-04 10:27:34 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
// If we have reached this point, then we have successfully changed the value.
SetNeedsUpdate();
return true;
<rdar://problem/11113279> Fixed type lookups to "do the right thing". Prior to this fix, looking up a type using "foo::bar" would result in a type list that contains all types that had "bar" as a basename unless the symbol file was able to match fully qualified names (which our DWARF parser does not). This fix will allow type matches to be made based on the basename and then have the types that don't match filtered out. Types by name can be fully qualified, or partially qualified with the new "bool exact_match" parameter to the Module::FindTypes() method. This fixes some issue that we discovered with dynamic type resolution as well as improves the overall type lookups in LLDB. llvm-svn: 153482
2012-03-27 07:03:23 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
bool ValueObject::GetDeclaration(Declaration &decl) {
decl.Clear();
return false;
Introduce the concept of a "display name" for types Rationale: Pretty simply, the idea is that sometimes type names are way too long and contain way too many details for the average developer to care about. For instance, a plain ol' vector of int might be shown as std::__1::vector<int, std::__1::allocator<.... rather than the much simpler std::vector<int> form, which is what most developers would actually type in their code Proposed solution: Introduce a notion of "display name" and a corresponding API GetDisplayTypeName() to return such a crafted for visual representation type name Obviously, the display name and the fully qualified (or "true") name are not necessarily the same - that's the whole point LLDB could choose to pick the "display name" as its one true notion of a type name, and if somebody really needs the fully qualified version of it, let them deal with the problem Or, LLDB could rename what it currently calls the "type name" to be the "display name", and add new APIs for the fully qualified name, making the display name the default choice The choice that I am making here is that the type name will keep meaning the same, and people who want a type name suited for display will explicitly ask for one It is the less risky/disruptive choice - and it should eventually make it fairly obvious when someone is asking for the wrong type Caveats: - for now, GetDisplayTypeName() == GetTypeName(), there is no logic to produce customized display type names yet. - while the fully-qualified type name is still the main key to the kingdom of data formatters, if we start showing custom names to people, those should match formatters llvm-svn: 209072
2014-05-18 03:14:17 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ConstString ValueObject::GetTypeName() {
return GetCompilerType().GetConstTypeName();
<rdar://problem/11113279> Fixed type lookups to "do the right thing". Prior to this fix, looking up a type using "foo::bar" would result in a type list that contains all types that had "bar" as a basename unless the symbol file was able to match fully qualified names (which our DWARF parser does not). This fix will allow type matches to be made based on the basename and then have the types that don't match filtered out. Types by name can be fully qualified, or partially qualified with the new "bool exact_match" parameter to the Module::FindTypes() method. This fixes some issue that we discovered with dynamic type resolution as well as improves the overall type lookups in LLDB. llvm-svn: 153482
2012-03-27 07:03:23 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ConstString ValueObject::GetDisplayTypeName() { return GetTypeName(); }
<rdar://problem/11113279> Fixed type lookups to "do the right thing". Prior to this fix, looking up a type using "foo::bar" would result in a type list that contains all types that had "bar" as a basename unless the symbol file was able to match fully qualified names (which our DWARF parser does not). This fix will allow type matches to be made based on the basename and then have the types that don't match filtered out. Types by name can be fully qualified, or partially qualified with the new "bool exact_match" parameter to the Module::FindTypes() method. This fixes some issue that we discovered with dynamic type resolution as well as improves the overall type lookups in LLDB. llvm-svn: 153482
2012-03-27 07:03:23 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ConstString ValueObject::GetQualifiedTypeName() {
return GetCompilerType().GetConstQualifiedTypeName();
Replace the vestigial Value::GetOpaqueCLangQualType with the more correct Value::GetValueOpaqueClangQualType. But mostly, move the ObjC Trampoline handling code from the MacOSX dyld plugin to the AppleObjCRuntime classes. llvm-svn: 114935
2010-09-28 09:25:32 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
LanguageType ValueObject::GetObjectRuntimeLanguage() {
return GetCompilerType().GetMinimumLanguage();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
void ValueObject::AddSyntheticChild(const ConstString &key,
ValueObject *valobj) {
m_synthetic_children[key] = valobj;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ValueObjectSP ValueObject::GetSyntheticChild(const ConstString &key) const {
ValueObjectSP synthetic_child_sp;
std::map<ConstString, ValueObject *>::const_iterator pos =
m_synthetic_children.find(key);
if (pos != m_synthetic_children.end())
synthetic_child_sp = pos->second->GetSP();
return synthetic_child_sp;
Fixed 2 more issues found by the address sanitizer: 1 - A store off the end of a buffer in ValueObject.cpp 2 - DataExtractor had cases where bad offsets could cause invalid memory to be accessed. llvm-svn: 174757
2013-02-09 06:02:02 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
uint32_t
ValueObject::GetTypeInfo(CompilerType *pointee_or_element_compiler_type) {
return GetCompilerType().GetTypeInfo(pointee_or_element_compiler_type);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
bool ValueObject::IsPointerType() { return GetCompilerType().IsPointerType(); }
Fixed the global and static variables to always be in scope. Made it so that you can create synthetic children of array value objects. This is for creating array members when the array index is out of range. This comes in handy when you have a structure definition like: struct Collection { uint32_t count; Item array[0]; }; "array" has 1 item, but many times in practice there are more items in "item_array". This allows you to do: (lldb) target variable g_collection.array[3] To implement this, the get child at index has been modified to have a "ignore_array_bounds" boolean that can be set to true. llvm-svn: 134846
2011-07-10 04:12:33 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
bool ValueObject::IsArrayType() {
return GetCompilerType().IsArrayType(NULL, NULL, NULL);
new syntax for summary strings: - ${*expr} now simply means to dereference expr before actually using it - bitfields, array ranges and pointer ranges now work in a (hopefully) more natural and language-compliant way a new class TypeHierarchyNavigator replicates the behavior of the FormatManager in going through type hierarchies when one-lining summary strings, children's summaries can be used as well as values llvm-svn: 134458
2011-07-06 10:13:41 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
bool ValueObject::IsScalarType() { return GetCompilerType().IsScalarType(); }
bool ValueObject::IsIntegerType(bool &is_signed) {
return GetCompilerType().IsIntegerType(is_signed);
Relax the constraint on the types of ValueObjects that we'll by default try the ObjC runtime for print object to Pointer AND Integer (from just pointer.) llvm-svn: 127841
2011-03-18 08:05:18 +08:00
}
Updated the lldb_private::Flags class to have better method names and made all of the calls inlined in the header file for better performance. Fixed the summary for C string types (array of chars (with any combo if modifiers), and pointers to chars) work in all cases. Fixed an issue where a forward declaration to a clang type could cause itself to resolve itself more than once if, during the resolving of the type itself it caused something to try and resolve itself again. We now remove the clang type from the forward declaration map in the DWARF parser when we start to resolve it and avoid this additional call. This should stop any duplicate members from appearing and throwing all the alignment of structs, unions and classes. llvm-svn: 117437
2010-10-27 11:32:59 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
bool ValueObject::IsPointerOrReferenceType() {
return GetCompilerType().IsPointerOrReferenceType();
lldb-59. llvm-svn: 132304
2011-05-30 08:49:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
bool ValueObject::IsPossibleDynamicType() {
ExecutionContext exe_ctx(GetExecutionContextRef());
Process *process = exe_ctx.GetProcessPtr();
if (process)
return process->IsPossibleDynamicValue(*this);
else
return GetCompilerType().IsPossibleDynamicType(NULL, true, true);
Added support for finding and global variables in the SBTarget and SBModule level in the public API. Also modified the ValueObject values to be able to display global variables without having a valid running process. The globals will read themselves from the object file section data if there is no process, and from the process if there is one. Also fixed an issue where modifications for dynamic types could cause child values of ValueObjects to not show up if the value was unable to evaluate itself (children of NULL pointer objects). llvm-svn: 134102
2011-06-30 06:09:02 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
bool ValueObject::IsRuntimeSupportValue() {
Process *process(GetProcessSP().get());
if (process) {
LanguageRuntime *runtime =
process->GetLanguageRuntime(GetObjectRuntimeLanguage());
if (!runtime)
runtime = process->GetObjCLanguageRuntime();
if (runtime)
return runtime->IsRuntimeSupportValue(*this);
}
return false;
Introduce the notion of "runtime support values" 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
2015-02-11 10:35:39 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
bool ValueObject::IsNilReference() {
if (Language *language = Language::FindPlugin(GetObjectRuntimeLanguage())) {
return language->IsNilReference(*this);
}
return false;
Introduce a way for Languages to specify whether values of "reference types" 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
2015-11-11 06:39:15 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
bool ValueObject::IsUninitializedReference() {
if (Language *language = Language::FindPlugin(GetObjectRuntimeLanguage())) {
return language->IsUninitializedReference(*this);
}
return false;
<rdar://problem/11689939> Supporting a compact display syntax for ObjC pointers where 0x00.....0 is replaced by a much more legible "nil" e.g. this would show: (NSArray *) $2 = nil instead of: (NSArray *) $2 = 0x0000000000000000 <nil> llvm-svn: 170161
2012-12-14 07:50:33 +08:00
}
Fixed the global and static variables to always be in scope. Made it so that you can create synthetic children of array value objects. This is for creating array members when the array index is out of range. This comes in handy when you have a structure definition like: struct Collection { uint32_t count; Item array[0]; }; "array" has 1 item, but many times in practice there are more items in "item_array". This allows you to do: (lldb) target variable g_collection.array[3] To implement this, the get child at index has been modified to have a "ignore_array_bounds" boolean that can be set to true. llvm-svn: 134846
2011-07-10 04:12:33 +08:00
// This allows you to create an array member using and index
// that doesn't not fall in the normal bounds of the array.
// Many times structure can be defined as:
// struct Collection
// {
// uint32_t item_count;
// Item item_array[0];
// };
// The size of the "item_array" is 1, but many times in practice
// there are more items in "item_array".
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ValueObjectSP ValueObject::GetSyntheticArrayMember(size_t index,
bool can_create) {
ValueObjectSP synthetic_child_sp;
if (IsPointerType() || IsArrayType()) {
char index_str[64];
snprintf(index_str, sizeof(index_str), "[%" PRIu64 "]", (uint64_t)index);
ConstString index_const_str(index_str);
Public API changes: - Completely new implementation of SBType - Various enhancements in several other classes Python synthetic children providers for std::vector<T>, std::list<T> and std::map<K,V>: - these return the actual elements into the container as the children of the container - basic template name parsing that works (hopefully) on both Clang and GCC - find them in examples/synthetic and in the test suite in functionalities/data-formatter/data-formatter-python-synth New summary string token ${svar : - the syntax is just the same as in ${var but this new token lets you read the values coming from the synthetic children provider instead of the actual children - Python providers above provide a synthetic child len that returns the number of elements into the container Full bug fix for the issue in which getting byte size for a non-complete type would crash LLDB Several other fixes, including: - inverted the order of arguments in the ClangASTType constructor - EvaluationPoint now only returns SharedPointer's to Target and Process - the help text for several type subcommands now correctly indicates argument-less options as such llvm-svn: 136504
2011-07-30 03:53:35 +08:00
// Check if we have already created a synthetic array member in this
// valid object. If we have we will re-use it.
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
synthetic_child_sp = GetSyntheticChild(index_const_str);
if (!synthetic_child_sp) {
ValueObject *synthetic_child;
// We haven't made a synthetic array member for INDEX yet, so
// lets make one and cache it for any future reference.
synthetic_child = CreateChildAtIndex(0, true, index);
// Cache the value if we got one back...
if (synthetic_child) {
AddSyntheticChild(index_const_str, synthetic_child);
Public API changes: - Completely new implementation of SBType - Various enhancements in several other classes Python synthetic children providers for std::vector<T>, std::list<T> and std::map<K,V>: - these return the actual elements into the container as the children of the container - basic template name parsing that works (hopefully) on both Clang and GCC - find them in examples/synthetic and in the test suite in functionalities/data-formatter/data-formatter-python-synth New summary string token ${svar : - the syntax is just the same as in ${var but this new token lets you read the values coming from the synthetic children provider instead of the actual children - Python providers above provide a synthetic child len that returns the number of elements into the container Full bug fix for the issue in which getting byte size for a non-complete type would crash LLDB Several other fixes, including: - inverted the order of arguments in the ClangASTType constructor - EvaluationPoint now only returns SharedPointer's to Target and Process - the help text for several type subcommands now correctly indicates argument-less options as such llvm-svn: 136504
2011-07-30 03:53:35 +08:00
synthetic_child_sp = synthetic_child->GetSP();
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
synthetic_child_sp->SetName(ConstString(index_str));
synthetic_child_sp->m_is_array_item_for_pointer = true;
}
Public API changes: - Completely new implementation of SBType - Various enhancements in several other classes Python synthetic children providers for std::vector<T>, std::list<T> and std::map<K,V>: - these return the actual elements into the container as the children of the container - basic template name parsing that works (hopefully) on both Clang and GCC - find them in examples/synthetic and in the test suite in functionalities/data-formatter/data-formatter-python-synth New summary string token ${svar : - the syntax is just the same as in ${var but this new token lets you read the values coming from the synthetic children provider instead of the actual children - Python providers above provide a synthetic child len that returns the number of elements into the container Full bug fix for the issue in which getting byte size for a non-complete type would crash LLDB Several other fixes, including: - inverted the order of arguments in the ClangASTType constructor - EvaluationPoint now only returns SharedPointer's to Target and Process - the help text for several type subcommands now correctly indicates argument-less options as such llvm-svn: 136504
2011-07-30 03:53:35 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
return synthetic_child_sp;
Public API changes: - Completely new implementation of SBType - Various enhancements in several other classes Python synthetic children providers for std::vector<T>, std::list<T> and std::map<K,V>: - these return the actual elements into the container as the children of the container - basic template name parsing that works (hopefully) on both Clang and GCC - find them in examples/synthetic and in the test suite in functionalities/data-formatter/data-formatter-python-synth New summary string token ${svar : - the syntax is just the same as in ${var but this new token lets you read the values coming from the synthetic children provider instead of the actual children - Python providers above provide a synthetic child len that returns the number of elements into the container Full bug fix for the issue in which getting byte size for a non-complete type would crash LLDB Several other fixes, including: - inverted the order of arguments in the ClangASTType constructor - EvaluationPoint now only returns SharedPointer's to Target and Process - the help text for several type subcommands now correctly indicates argument-less options as such llvm-svn: 136504
2011-07-30 03:53:35 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ValueObjectSP ValueObject::GetSyntheticBitFieldChild(uint32_t from, uint32_t to,
bool can_create) {
ValueObjectSP synthetic_child_sp;
if (IsScalarType()) {
char index_str[64];
snprintf(index_str, sizeof(index_str), "[%i-%i]", from, to);
ConstString index_const_str(index_str);
Add an API on ValueObject to generate a 'synthetic child' of base class 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
2014-08-27 04:54:04 +08:00
// Check if we have already created a synthetic array member in this
// valid object. If we have we will re-use it.
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
synthetic_child_sp = GetSyntheticChild(index_const_str);
if (!synthetic_child_sp) {
uint32_t bit_field_size = to - from + 1;
uint32_t bit_field_offset = from;
if (GetDataExtractor().GetByteOrder() == eByteOrderBig)
bit_field_offset =
GetByteSize() * 8 - bit_field_size - bit_field_offset;
// We haven't made a synthetic array member for INDEX yet, so
// lets make one and cache it for any future reference.
ValueObjectChild *synthetic_child = new ValueObjectChild(
*this, GetCompilerType(), index_const_str, GetByteSize(), 0,
bit_field_size, bit_field_offset, false, false, eAddressTypeInvalid,
0);
// Cache the value if we got one back...
if (synthetic_child) {
AddSyntheticChild(index_const_str, synthetic_child);
Add an API on ValueObject to generate a 'synthetic child' of base class 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
2014-08-27 04:54:04 +08:00
synthetic_child_sp = synthetic_child->GetSP();
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
synthetic_child_sp->SetName(ConstString(index_str));
synthetic_child_sp->m_is_bitfield_for_scalar = true;
}
Add an API on ValueObject to generate a 'synthetic child' of base class 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
2014-08-27 04:54:04 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
return synthetic_child_sp;
Add an API on ValueObject to generate a 'synthetic child' of base class 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
2014-08-27 04:54:04 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ValueObjectSP ValueObject::GetSyntheticChildAtOffset(
uint32_t offset, const CompilerType &type, bool can_create,
ConstString name_const_str) {
ValueObjectSP synthetic_child_sp;
if (name_const_str.IsEmpty()) {
char name_str[64];
snprintf(name_str, sizeof(name_str), "@%i", offset);
name_const_str.SetCString(name_str);
}
// Check if we have already created a synthetic array member in this
// valid object. If we have we will re-use it.
synthetic_child_sp = GetSyntheticChild(name_const_str);
if (synthetic_child_sp.get())
return synthetic_child_sp;
if (!can_create)
return ValueObjectSP();
ExecutionContext exe_ctx(GetExecutionContextRef());
ValueObjectChild *synthetic_child = new ValueObjectChild(
*this, type, name_const_str,
type.GetByteSize(exe_ctx.GetBestExecutionContextScope()), offset, 0, 0,
false, false, eAddressTypeInvalid, 0);
if (synthetic_child) {
AddSyntheticChild(name_const_str, synthetic_child);
synthetic_child_sp = synthetic_child->GetSP();
synthetic_child_sp->SetName(name_const_str);
synthetic_child_sp->m_is_child_at_offset = true;
}
return synthetic_child_sp;
}
ValueObjectSP ValueObject::GetSyntheticBase(uint32_t offset,
const CompilerType &type,
bool can_create,
ConstString name_const_str) {
ValueObjectSP synthetic_child_sp;
if (name_const_str.IsEmpty()) {
char name_str[128];
snprintf(name_str, sizeof(name_str), "base%s@%i",
type.GetTypeName().AsCString("<unknown>"), offset);
name_const_str.SetCString(name_str);
}
// Check if we have already created a synthetic array member in this
// valid object. If we have we will re-use it.
synthetic_child_sp = GetSyntheticChild(name_const_str);
if (synthetic_child_sp.get())
return synthetic_child_sp;
if (!can_create)
return ValueObjectSP();
const bool is_base_class = true;
ExecutionContext exe_ctx(GetExecutionContextRef());
ValueObjectChild *synthetic_child = new ValueObjectChild(
*this, type, name_const_str,
type.GetByteSize(exe_ctx.GetBestExecutionContextScope()), offset, 0, 0,
is_base_class, false, eAddressTypeInvalid, 0);
if (synthetic_child) {
AddSyntheticChild(name_const_str, synthetic_child);
synthetic_child_sp = synthetic_child->GetSP();
synthetic_child_sp->SetName(name_const_str);
}
return synthetic_child_sp;
}
Add an API on ValueObject to generate a 'synthetic child' of base class 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
2014-08-27 04:54:04 +08:00
when typing a summary string you can use the %S symbol to explicitly indicate that you want the summary to be used to print the target object (e.g. ${var%S}). this might already be the default if your variable is of an aggregate type new feature: synthetic filters. you can restrict the number of children for your variables to only a meaningful subset - the restricted list of children obeys the typical rules (e.g. summaries prevail over children) - one-line summaries show only the filtered (synthetic) children, if you type an expanded summary string, or you use Python scripts, all the real children are accessible - to provide a synthetic children list use the "type synth add" command, as in: type synth add foo_type --child varA --child varB[0] --child varC->packet->flags[1-4] (you can use ., ->, single-item array operator [N] and bitfield operator [N-M]; array slice access is not supported, giving simplified names to expression paths is not supported) - a new -S option to frame variable and target variable lets you override synthetic children and instead show real ones llvm-svn: 135731
2011-07-22 08:16:08 +08:00
// your expression path needs to have a leading . or ->
// (unless it somehow "looks like" an array, in which case it has
// a leading [ symbol). while the [ is meaningful and should be shown
// to the user, . and -> are just parser design, but by no means
// added information for the user.. strip them off
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
static const char *SkipLeadingExpressionPathSeparators(const char *expression) {
if (!expression || !expression[0])
when typing a summary string you can use the %S symbol to explicitly indicate that you want the summary to be used to print the target object (e.g. ${var%S}). this might already be the default if your variable is of an aggregate type new feature: synthetic filters. you can restrict the number of children for your variables to only a meaningful subset - the restricted list of children obeys the typical rules (e.g. summaries prevail over children) - one-line summaries show only the filtered (synthetic) children, if you type an expanded summary string, or you use Python scripts, all the real children are accessible - to provide a synthetic children list use the "type synth add" command, as in: type synth add foo_type --child varA --child varB[0] --child varC->packet->flags[1-4] (you can use ., ->, single-item array operator [N] and bitfield operator [N-M]; array slice access is not supported, giving simplified names to expression paths is not supported) - a new -S option to frame variable and target variable lets you override synthetic children and instead show real ones llvm-svn: 135731
2011-07-22 08:16:08 +08:00
return expression;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (expression[0] == '.')
return expression + 1;
if (expression[0] == '-' && expression[1] == '>')
return expression + 2;
return expression;
when typing a summary string you can use the %S symbol to explicitly indicate that you want the summary to be used to print the target object (e.g. ${var%S}). this might already be the default if your variable is of an aggregate type new feature: synthetic filters. you can restrict the number of children for your variables to only a meaningful subset - the restricted list of children obeys the typical rules (e.g. summaries prevail over children) - one-line summaries show only the filtered (synthetic) children, if you type an expanded summary string, or you use Python scripts, all the real children are accessible - to provide a synthetic children list use the "type synth add" command, as in: type synth add foo_type --child varA --child varB[0] --child varC->packet->flags[1-4] (you can use ., ->, single-item array operator [N] and bitfield operator [N-M]; array slice access is not supported, giving simplified names to expression paths is not supported) - a new -S option to frame variable and target variable lets you override synthetic children and instead show real ones llvm-svn: 135731
2011-07-22 08:16:08 +08:00
}
Added the ability for DWARF locations to use the ABI plug-ins to resolve register names when dumping variable locations and location lists. Also did some cleanup where "int" types were being used for "lldb::RegisterKind" values. llvm-svn: 138988
2011-09-02 09:15:17 +08:00
ValueObjectSP
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ValueObject::GetSyntheticExpressionPathChild(const char *expression,
bool can_create) {
ValueObjectSP synthetic_child_sp;
ConstString name_const_string(expression);
// Check if we have already created a synthetic array member in this
// valid object. If we have we will re-use it.
synthetic_child_sp = GetSyntheticChild(name_const_string);
if (!synthetic_child_sp) {
// We haven't made a synthetic array member for expression yet, so
// lets make one and cache it for any future reference.
synthetic_child_sp = GetValueForExpressionPath(
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
expression, NULL, NULL,
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
GetValueForExpressionPathOptions().SetSyntheticChildrenTraversal(
GetValueForExpressionPathOptions::SyntheticChildrenTraversal::
None));
// Cache the value if we got one back...
if (synthetic_child_sp.get()) {
// FIXME: this causes a "real" child to end up with its name changed to
// the contents of expression
AddSyntheticChild(name_const_string, synthetic_child_sp.get());
synthetic_child_sp->SetName(
ConstString(SkipLeadingExpressionPathSeparators(expression)));
}
}
return synthetic_child_sp;
}
void ValueObject::CalculateSyntheticValue(bool use_synthetic) {
if (use_synthetic == false)
return;
TargetSP target_sp(GetTargetSP());
if (target_sp && target_sp->GetEnableSyntheticValue() == false) {
m_synthetic_value = NULL;
return;
}
lldb::SyntheticChildrenSP current_synth_sp(m_synthetic_children_sp);
if (!UpdateFormatsIfNeeded() && m_synthetic_value)
return;
if (m_synthetic_children_sp.get() == NULL)
return;
if (current_synth_sp == m_synthetic_children_sp && m_synthetic_value)
return;
m_synthetic_value = new ValueObjectSynthetic(*this, m_synthetic_children_sp);
}
void ValueObject::CalculateDynamicValue(DynamicValueType use_dynamic) {
if (use_dynamic == eNoDynamicValues)
return;
if (!m_dynamic_value && !IsDynamic()) {
ExecutionContext exe_ctx(GetExecutionContextRef());
Process *process = exe_ctx.GetProcessPtr();
if (process && process->IsPossibleDynamicValue(*this)) {
ClearDynamicTypeInformation();
m_dynamic_value = new ValueObjectDynamicValue(*this, use_dynamic);
when typing a summary string you can use the %S symbol to explicitly indicate that you want the summary to be used to print the target object (e.g. ${var%S}). this might already be the default if your variable is of an aggregate type new feature: synthetic filters. you can restrict the number of children for your variables to only a meaningful subset - the restricted list of children obeys the typical rules (e.g. summaries prevail over children) - one-line summaries show only the filtered (synthetic) children, if you type an expanded summary string, or you use Python scripts, all the real children are accessible - to provide a synthetic children list use the "type synth add" command, as in: type synth add foo_type --child varA --child varB[0] --child varC->packet->flags[1-4] (you can use ., ->, single-item array operator [N] and bitfield operator [N-M]; array slice access is not supported, giving simplified names to expression paths is not supported) - a new -S option to frame variable and target variable lets you override synthetic children and instead show real ones llvm-svn: 135731
2011-07-22 08:16:08 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
when typing a summary string you can use the %S symbol to explicitly indicate that you want the summary to be used to print the target object (e.g. ${var%S}). this might already be the default if your variable is of an aggregate type new feature: synthetic filters. you can restrict the number of children for your variables to only a meaningful subset - the restricted list of children obeys the typical rules (e.g. summaries prevail over children) - one-line summaries show only the filtered (synthetic) children, if you type an expanded summary string, or you use Python scripts, all the real children are accessible - to provide a synthetic children list use the "type synth add" command, as in: type synth add foo_type --child varA --child varB[0] --child varC->packet->flags[1-4] (you can use ., ->, single-item array operator [N] and bitfield operator [N-M]; array slice access is not supported, giving simplified names to expression paths is not supported) - a new -S option to frame variable and target variable lets you override synthetic children and instead show real ones llvm-svn: 135731
2011-07-22 08:16:08 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ValueObjectSP ValueObject::GetDynamicValue(DynamicValueType use_dynamic) {
if (use_dynamic == eNoDynamicValues)
return ValueObjectSP();
when typing a summary string you can use the %S symbol to explicitly indicate that you want the summary to be used to print the target object (e.g. ${var%S}). this might already be the default if your variable is of an aggregate type new feature: synthetic filters. you can restrict the number of children for your variables to only a meaningful subset - the restricted list of children obeys the typical rules (e.g. summaries prevail over children) - one-line summaries show only the filtered (synthetic) children, if you type an expanded summary string, or you use Python scripts, all the real children are accessible - to provide a synthetic children list use the "type synth add" command, as in: type synth add foo_type --child varA --child varB[0] --child varC->packet->flags[1-4] (you can use ., ->, single-item array operator [N] and bitfield operator [N-M]; array slice access is not supported, giving simplified names to expression paths is not supported) - a new -S option to frame variable and target variable lets you override synthetic children and instead show real ones llvm-svn: 135731
2011-07-22 08:16:08 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (!IsDynamic() && m_dynamic_value == NULL) {
CalculateDynamicValue(use_dynamic);
}
if (m_dynamic_value)
return m_dynamic_value->GetSP();
else
return ValueObjectSP();
Add support for "dynamic values" for C++ classes. This currently only works for "frame var" and for the expressions that are simple enough to get passed to the "frame var" underpinnings. The parser code will have to be changed to also query for the dynamic types & offsets as it is looking up variables. The behavior of "frame var" is controlled in two ways. You can pass "-d {true/false} to the frame var command to get the dynamic or static value of the variables you are printing. There's also a general setting: target.prefer-dynamic-value (boolean) = 'true' which is consulted if you call "frame var" without supplying a value for the -d option. llvm-svn: 129623
2011-04-16 08:01:13 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ValueObjectSP ValueObject::GetStaticValue() { return GetSP(); }
Added a new ValueObject type that will be used to freeze dry expression results. The clang opaque type for the expression result will be added to the Target's ASTContext, and the bytes will be stored in a DataBuffer inside the new object. The class is named: ValueObjectConstResult Now after an expression is evaluated, we can get a ValueObjectSP back that contains a ValueObjectConstResult object. Relocated the value object dumping code into a static function within the ValueObject class instead of being in the CommandObjectFrame.cpp file which is what contained the code to dump variables ("frame variables"). llvm-svn: 115578
2010-10-05 08:00:42 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
lldb::ValueObjectSP ValueObject::GetNonSyntheticValue() { return GetSP(); }
Add SBValue::GetDynamicValue and SBValue::GetStaticValue API's. <rdar://problem/10545069> llvm-svn: 146173
2011-12-09 03:44:08 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ValueObjectSP ValueObject::GetSyntheticValue(bool use_synthetic) {
if (use_synthetic == false)
return ValueObjectSP();
CalculateSyntheticValue(use_synthetic);
if (m_synthetic_value)
return m_synthetic_value->GetSP();
else
return ValueObjectSP();
First part of a fix to make GetNonSyntheticValue() work correctly llvm-svn: 156397
2012-05-09 02:47:08 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
bool ValueObject::HasSyntheticValue() {
UpdateFormatsIfNeeded();
Massive enumeration name changes: a number of enums in ValueObject were not following the naming pattern Changes to synthetic children: - the update(self): function can now (optionally) return a value - if it returns boolean value True, ValueObjectSyntheticFilter will not clear its caches across stop-points this should allow better performance for Python-based synthetic children when one can be sure that the child ValueObjects have not changed - making a difference between a synthetic VO and a VO with a synthetic value: now a ValueObjectSyntheticFilter will not return itself as its own synthetic value, but will (correctly) claim to itself be synthetic - cleared up the internal synthetic children architecture to make a more consistent use of pointers and references instead of shared pointers when possible - major cleanup of unnecessary #include, data and functions in ValueObjectSyntheticFilter itself - removed the SyntheticValueType enum and replaced it with a plain boolean (to which it was equivalent in the first place) Some clean ups to the summary generation code Centralized the code that clears out user-visible strings and data in ValueObject More efficient summaries for libc++ containers llvm-svn: 153061
2012-03-20 06:58:49 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (m_synthetic_children_sp.get() == NULL)
return false;
when typing a summary string you can use the %S symbol to explicitly indicate that you want the summary to be used to print the target object (e.g. ${var%S}). this might already be the default if your variable is of an aggregate type new feature: synthetic filters. you can restrict the number of children for your variables to only a meaningful subset - the restricted list of children obeys the typical rules (e.g. summaries prevail over children) - one-line summaries show only the filtered (synthetic) children, if you type an expanded summary string, or you use Python scripts, all the real children are accessible - to provide a synthetic children list use the "type synth add" command, as in: type synth add foo_type --child varA --child varB[0] --child varC->packet->flags[1-4] (you can use ., ->, single-item array operator [N] and bitfield operator [N-M]; array slice access is not supported, giving simplified names to expression paths is not supported) - a new -S option to frame variable and target variable lets you override synthetic children and instead show real ones llvm-svn: 135731
2011-07-22 08:16:08 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
CalculateSyntheticValue(true);
Basic support for reading synthetic children by index: if your datatype provides synthetic children, "frame variable object[index]" should now do the right thing in cases where the above syntax would have been rejected before, i.e. object is not a pointer nor an array (frame variable ignores potential overload of []) object is a pointer to an Objective-C class (which cannot be dereferenced) expression will still run operator[] if available and complain if it cannot do so synthetic children by name do not work yet llvm-svn: 137097
2011-08-09 09:04:56 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (m_synthetic_value)
return true;
else
Fixed up the SBValue::GetExpressionPath() to be more correct under more circumstances. llvm-svn: 123957
2011-01-21 09:59:00 +08:00
return false;
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
bool ValueObject::GetBaseClassPath(Stream &s) {
if (IsBaseClass()) {
bool parent_had_base_class =
GetParent() && GetParent()->GetBaseClassPath(s);
CompilerType compiler_type = GetCompilerType();
std::string cxx_class_name;
bool this_had_base_class =
ClangASTContext::GetCXXClassName(compiler_type, cxx_class_name);
if (this_had_base_class) {
if (parent_had_base_class)
s.PutCString("::");
Fix Clang-tidy readability-redundant-string-cstr warnings Reviewers: zturner, labath Subscribers: tberghammer, danalbert, lldb-commits Differential Revision: https://reviews.llvm.org/D26233 llvm-svn: 285855
2016-11-03 04:34:10 +08:00
s.PutCString(cxx_class_name);
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
return parent_had_base_class || this_had_base_class;
}
return false;
}
ValueObject *ValueObject::GetNonBaseClassParent() {
if (GetParent()) {
if (GetParent()->IsBaseClass())
return GetParent()->GetNonBaseClassParent();
else
return GetParent();
}
return NULL;
Fixed up the SBValue::GetExpressionPath() to be more correct under more circumstances. llvm-svn: 123957
2011-01-21 09:59:00 +08:00
}
Added a new ValueObject type that will be used to freeze dry expression results. The clang opaque type for the expression result will be added to the Target's ASTContext, and the bytes will be stored in a DataBuffer inside the new object. The class is named: ValueObjectConstResult Now after an expression is evaluated, we can get a ValueObjectSP back that contains a ValueObjectConstResult object. Relocated the value object dumping code into a static function within the ValueObject class instead of being in the CommandObjectFrame.cpp file which is what contained the code to dump variables ("frame variables"). llvm-svn: 115578
2010-10-05 08:00:42 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
bool ValueObject::IsBaseClass(uint32_t &depth) {
if (!IsBaseClass()) {
depth = 0;
return false;
}
if (GetParent()) {
GetParent()->IsBaseClass(depth);
depth = depth + 1;
Add an accessor to ValueObject that determines if the object represents a 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
2014-08-20 06:29:08 +08:00
return true;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
// TODO: a base of no parent? weird..
depth = 1;
return true;
}
void ValueObject::GetExpressionPath(Stream &s, bool qualify_cxx_base_classes,
GetExpressionPathFormat epformat) {
// synthetic children do not actually "exist" as part of the hierarchy, and
// sometimes they are consed up in ways
// that don't make sense from an underlying language/API standpoint. So, use a
// special code path here to return
// something that can hopefully be used in expression
if (m_is_synthetic_children_generated) {
UpdateValueIfNeeded();
Add an accessor to ValueObject that determines if the object represents a 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
2014-08-20 06:29:08 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (m_value.GetValueType() == Value::eValueTypeLoadAddress) {
if (IsPointerOrReferenceType()) {
s.Printf("((%s)0x%" PRIx64 ")", GetTypeName().AsCString("void"),
GetValueAsUnsigned(0));
Extend ValueObject::GetExpressionPath() to do something reasonable for 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
2014-12-10 05:41:16 +08:00
return;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
} else {
uint64_t load_addr =
m_value.GetScalar().ULongLong(LLDB_INVALID_ADDRESS);
if (load_addr != LLDB_INVALID_ADDRESS) {
s.Printf("(*( (%s *)0x%" PRIx64 "))", GetTypeName().AsCString("void"),
load_addr);
return;
}
}
}
if (CanProvideValue()) {
s.Printf("((%s)%s)", GetTypeName().AsCString("void"),
GetValueAsCString());
return;
}
return;
}
const bool is_deref_of_parent = IsDereferenceOfParent();
if (is_deref_of_parent &&
epformat == eGetExpressionPathFormatDereferencePointers) {
// this is the original format of GetExpressionPath() producing code like
// *(a_ptr).memberName, which is entirely
// fine, until you put this into
// StackFrame::GetValueForVariableExpressionPath() which prefers to see
// a_ptr->memberName.
// the eHonorPointers mode is meant to produce strings in this latter format
s.PutCString("*(");
}
ValueObject *parent = GetParent();
if (parent)
parent->GetExpressionPath(s, qualify_cxx_base_classes, epformat);
// if we are a deref_of_parent just because we are synthetic array
// members made up to allow ptr[%d] syntax to work in variable
// printing, then add our name ([%d]) to the expression path
if (m_is_array_item_for_pointer &&
epformat == eGetExpressionPathFormatHonorPointers)
s.PutCString(m_name.AsCString());
if (!IsBaseClass()) {
if (!is_deref_of_parent) {
ValueObject *non_base_class_parent = GetNonBaseClassParent();
if (non_base_class_parent &&
!non_base_class_parent->GetName().IsEmpty()) {
CompilerType non_base_class_parent_compiler_type =
non_base_class_parent->GetCompilerType();
if (non_base_class_parent_compiler_type) {
if (parent && parent->IsDereferenceOfParent() &&
epformat == eGetExpressionPathFormatHonorPointers) {
s.PutCString("->");
} else {
const uint32_t non_base_class_parent_type_info =
non_base_class_parent_compiler_type.GetTypeInfo();
if (non_base_class_parent_type_info & eTypeIsPointer) {
s.PutCString("->");
} else if ((non_base_class_parent_type_info & eTypeHasChildren) &&
!(non_base_class_parent_type_info & eTypeIsArray)) {
s.PutChar('.');
Fixed an expression parsing issue where if you were stopped somewhere without debug information and you evaluated an expression, a crash would occur as a result of an unchecked pointer. Added the ability to get the expression path for a ValueObject. For a rectangle point child "x" the expression path would be something like: "rect.top_left.x". This will allow GUI and command lines to get ahold of the expression path for a value object without having to explicitly know about the hierarchy. This means the ValueObject base class now has a "ValueObject *m_parent;" member. All ValueObject subclasses now correctly track their lineage and are able to provide value expression paths as well. Added a new "--flat" option to the "frame variable" to allow for flat variable output. An example of the current and new outputs: (lldb) frame variable argc = 1 argv = 0x00007fff5fbffe80 pt = { x = 2 y = 3 } rect = { bottom_left = { x = 1 y = 2 } top_right = { x = 3 y = 4 } } (lldb) frame variable --flat argc = 1 argv = 0x00007fff5fbffe80 pt.x = 2 pt.y = 3 rect.bottom_left.x = 1 rect.bottom_left.y = 2 rect.top_right.x = 3 rect.top_right.y = 4 As you can see when there is a lot of hierarchy it can help flatten things out. Also if you want to use a member in an expression, you can copy the text from the "--flat" output and not have to piece it together manually. This can help when you want to use parts of the STL in expressions: (lldb) frame variable --flat argc = 1 argv = 0x00007fff5fbffea8 hello_world._M_dataplus._M_p = 0x0000000000000000 (lldb) expr hello_world._M_dataplus._M_p[0] == '\0' llvm-svn: 116532
2010-10-15 06:52:14 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
}
}
const char *name = GetName().GetCString();
if (name) {
if (qualify_cxx_base_classes) {
if (GetBaseClassPath(s))
s.PutCString("::");
}
s.PutCString(name);
}
}
}
if (is_deref_of_parent &&
epformat == eGetExpressionPathFormatDereferencePointers) {
s.PutChar(')');
}
}
ValueObjectSP ValueObject::GetValueForExpressionPath(
Re-add the StringRef interface changes for Variable. 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
2016-11-19 03:23:39 +08:00
llvm::StringRef expression, ExpressionPathScanEndReason *reason_to_stop,
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ExpressionPathEndResultType *final_value_type,
const GetValueForExpressionPathOptions &options,
ExpressionPathAftermath *final_task_on_target) {
ExpressionPathScanEndReason dummy_reason_to_stop =
ValueObject::eExpressionPathScanEndReasonUnknown;
ExpressionPathEndResultType dummy_final_value_type =
ValueObject::eExpressionPathEndResultTypeInvalid;
ExpressionPathAftermath dummy_final_task_on_target =
ValueObject::eExpressionPathAftermathNothing;
ValueObjectSP ret_val = GetValueForExpressionPath_Impl(
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
expression, reason_to_stop ? reason_to_stop : &dummy_reason_to_stop,
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
final_value_type ? final_value_type : &dummy_final_value_type, options,
final_task_on_target ? final_task_on_target
: &dummy_final_task_on_target);
if (!final_task_on_target ||
*final_task_on_target == ValueObject::eExpressionPathAftermathNothing)
return ret_val;
if (ret_val.get() &&
((final_value_type ? *final_value_type : dummy_final_value_type) ==
eExpressionPathEndResultTypePlain)) // I can only deref and takeaddress
// of plain objects
{
if ((final_task_on_target ? *final_task_on_target
: dummy_final_task_on_target) ==
ValueObject::eExpressionPathAftermathDereference) {
Rename Error -> Status. 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
2017-05-12 12:51:55 +08:00
Status error;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ValueObjectSP final_value = ret_val->Dereference(error);
if (error.Fail() || !final_value.get()) {
if (reason_to_stop)
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonDereferencingFailed;
if (final_value_type)
*final_value_type = ValueObject::eExpressionPathEndResultTypeInvalid;
return ValueObjectSP();
} else {
if (final_task_on_target)
*final_task_on_target = ValueObject::eExpressionPathAftermathNothing;
return final_value;
}
}
if (*final_task_on_target ==
ValueObject::eExpressionPathAftermathTakeAddress) {
Rename Error -> Status. 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
2017-05-12 12:51:55 +08:00
Status error;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ValueObjectSP final_value = ret_val->AddressOf(error);
if (error.Fail() || !final_value.get()) {
if (reason_to_stop)
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonTakingAddressFailed;
if (final_value_type)
*final_value_type = ValueObject::eExpressionPathEndResultTypeInvalid;
return ValueObjectSP();
} else {
if (final_task_on_target)
*final_task_on_target = ValueObject::eExpressionPathAftermathNothing;
return final_value;
}
}
}
return ret_val; // final_task_on_target will still have its original value, so
// you know I did not do it
}
ValueObjectSP ValueObject::GetValueForExpressionPath_Impl(
Re-add the StringRef interface changes for Variable. 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
2016-11-19 03:23:39 +08:00
llvm::StringRef expression, ExpressionPathScanEndReason *reason_to_stop,
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ExpressionPathEndResultType *final_result,
const GetValueForExpressionPathOptions &options,
ExpressionPathAftermath *what_next) {
ValueObjectSP root = GetSP();
Re-add the StringRef interface changes for Variable. 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
2016-11-19 03:23:39 +08:00
if (!root)
return nullptr;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
Re-add the StringRef interface changes for Variable. 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
2016-11-19 03:23:39 +08:00
llvm::StringRef remainder = expression;
Revert "Remove an out param from ValueObject::GetValueForExpressionPath." This reverts commit r287315, as it introduces a bug that breaks many things. llvm-svn: 287320
2016-11-18 14:34:45 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
while (true) {
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
llvm::StringRef temp_expression = remainder;
Revert "Remove an out param from ValueObject::GetValueForExpressionPath." This reverts commit r287315, as it introduces a bug that breaks many things. llvm-svn: 287320
2016-11-18 14:34:45 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
CompilerType root_compiler_type = root->GetCompilerType();
CompilerType pointee_compiler_type;
Flags pointee_compiler_type_info;
Flags root_compiler_type_info(
root_compiler_type.GetTypeInfo(&pointee_compiler_type));
if (pointee_compiler_type)
pointee_compiler_type_info.Reset(pointee_compiler_type.GetTypeInfo());
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
if (temp_expression.empty()) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
*reason_to_stop = ValueObject::eExpressionPathScanEndReasonEndOfString;
return root;
}
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
switch (temp_expression.front()) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
case '-': {
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
temp_expression = temp_expression.drop_front();
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (options.m_check_dot_vs_arrow_syntax &&
root_compiler_type_info.Test(eTypeIsPointer)) // if you are trying to
// use -> on a
// non-pointer and I
// must catch the error
{
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonArrowInsteadOfDot;
*final_result = ValueObject::eExpressionPathEndResultTypeInvalid;
return ValueObjectSP();
}
if (root_compiler_type_info.Test(eTypeIsObjC) && // if yo are trying to
// extract an ObjC IVar
// when this is forbidden
root_compiler_type_info.Test(eTypeIsPointer) &&
options.m_no_fragile_ivar) {
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonFragileIVarNotAllowed;
*final_result = ValueObject::eExpressionPathEndResultTypeInvalid;
return ValueObjectSP();
}
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
if (!temp_expression.startswith(">")) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonUnexpectedSymbol;
*final_result = ValueObject::eExpressionPathEndResultTypeInvalid;
return ValueObjectSP();
}
}
LLVM_FALLTHROUGH;
case '.': // or fallthrough from ->
{
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
if (options.m_check_dot_vs_arrow_syntax &&
temp_expression.front() == '.' &&
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
root_compiler_type_info.Test(eTypeIsPointer)) // if you are trying to
// use . on a pointer
// and I must catch the
// error
{
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonDotInsteadOfArrow;
*final_result = ValueObject::eExpressionPathEndResultTypeInvalid;
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
return nullptr;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
temp_expression = temp_expression.drop_front(); // skip . or >
size_t next_sep_pos = temp_expression.find_first_of("-.[", 1);
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ConstString child_name;
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
if (next_sep_pos == llvm::StringRef::npos) // if no other separator just
// expand this last layer
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
{
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
child_name.SetString(temp_expression);
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ValueObjectSP child_valobj_sp =
root->GetChildMemberWithName(child_name, true);
if (child_valobj_sp.get()) // we know we are done, so just return
{
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonEndOfString;
*final_result = ValueObject::eExpressionPathEndResultTypePlain;
return child_valobj_sp;
} else {
switch (options.m_synthetic_children_traversal) {
case GetValueForExpressionPathOptions::SyntheticChildrenTraversal::
None:
break;
case GetValueForExpressionPathOptions::SyntheticChildrenTraversal::
FromSynthetic:
if (root->IsSynthetic()) {
child_valobj_sp = root->GetNonSyntheticValue();
if (child_valobj_sp.get())
child_valobj_sp =
child_valobj_sp->GetChildMemberWithName(child_name, true);
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
case GetValueForExpressionPathOptions::SyntheticChildrenTraversal::
ToSynthetic:
if (!root->IsSynthetic()) {
child_valobj_sp = root->GetSyntheticValue();
if (child_valobj_sp.get())
child_valobj_sp =
child_valobj_sp->GetChildMemberWithName(child_name, true);
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
case GetValueForExpressionPathOptions::SyntheticChildrenTraversal::
Both:
if (root->IsSynthetic()) {
child_valobj_sp = root->GetNonSyntheticValue();
if (child_valobj_sp.get())
child_valobj_sp =
child_valobj_sp->GetChildMemberWithName(child_name, true);
} else {
child_valobj_sp = root->GetSyntheticValue();
if (child_valobj_sp.get())
child_valobj_sp =
child_valobj_sp->GetChildMemberWithName(child_name, true);
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
}
}
// if we are here and options.m_no_synthetic_children is true,
// child_valobj_sp is going to be a NULL SP,
// so we hit the "else" branch, and return an error
if (child_valobj_sp.get()) // if it worked, just return
{
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonEndOfString;
*final_result = ValueObject::eExpressionPathEndResultTypePlain;
return child_valobj_sp;
} else {
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonNoSuchChild;
*final_result = ValueObject::eExpressionPathEndResultTypeInvalid;
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
return nullptr;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
} else // other layers do expand
{
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
llvm::StringRef next_separator = temp_expression.substr(next_sep_pos);
child_name.SetString(temp_expression.slice(0, next_sep_pos));
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ValueObjectSP child_valobj_sp =
root->GetChildMemberWithName(child_name, true);
if (child_valobj_sp.get()) // store the new root and move on
{
root = child_valobj_sp;
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
remainder = next_separator;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
*final_result = ValueObject::eExpressionPathEndResultTypePlain;
continue;
} else {
switch (options.m_synthetic_children_traversal) {
case GetValueForExpressionPathOptions::SyntheticChildrenTraversal::
None:
break;
case GetValueForExpressionPathOptions::SyntheticChildrenTraversal::
FromSynthetic:
if (root->IsSynthetic()) {
child_valobj_sp = root->GetNonSyntheticValue();
if (child_valobj_sp.get())
child_valobj_sp =
child_valobj_sp->GetChildMemberWithName(child_name, true);
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
case GetValueForExpressionPathOptions::SyntheticChildrenTraversal::
ToSynthetic:
if (!root->IsSynthetic()) {
child_valobj_sp = root->GetSyntheticValue();
if (child_valobj_sp.get())
child_valobj_sp =
child_valobj_sp->GetChildMemberWithName(child_name, true);
named summaries: - a new --name option for "type summary add" lets you give a name to a summary - a new --summary option for "frame variable" lets you bind a named summary to one or more variables ${var%s} now works for printing the value of 0-terminated CStrings type format test case now tests for cascading - this is disabled on GCC because GCC may end up stripping typedef chains, basically breaking cascading new design for the FormatNavigator class new template class CleanUp2 meant to support cleanup routines with 1 additional parameter beyond resource handle llvm-svn: 134943
2011-07-12 08:18:11 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
case GetValueForExpressionPathOptions::SyntheticChildrenTraversal::
Both:
if (root->IsSynthetic()) {
child_valobj_sp = root->GetNonSyntheticValue();
if (child_valobj_sp.get())
child_valobj_sp =
child_valobj_sp->GetChildMemberWithName(child_name, true);
} else {
child_valobj_sp = root->GetSyntheticValue();
if (child_valobj_sp.get())
child_valobj_sp =
child_valobj_sp->GetChildMemberWithName(child_name, true);
named summaries: - a new --name option for "type summary add" lets you give a name to a summary - a new --summary option for "frame variable" lets you bind a named summary to one or more variables ${var%s} now works for printing the value of 0-terminated CStrings type format test case now tests for cascading - this is disabled on GCC because GCC may end up stripping typedef chains, basically breaking cascading new design for the FormatNavigator class new template class CleanUp2 meant to support cleanup routines with 1 additional parameter beyond resource handle llvm-svn: 134943
2011-07-12 08:18:11 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
break;
}
}
// if we are here and options.m_no_synthetic_children is true,
// child_valobj_sp is going to be a NULL SP,
// so we hit the "else" branch, and return an error
if (child_valobj_sp.get()) // if it worked, move on
{
root = child_valobj_sp;
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
remainder = next_separator;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
*final_result = ValueObject::eExpressionPathEndResultTypePlain;
continue;
} else {
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonNoSuchChild;
*final_result = ValueObject::eExpressionPathEndResultTypeInvalid;
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
return nullptr;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
}
break;
}
case '[': {
if (!root_compiler_type_info.Test(eTypeIsArray) &&
!root_compiler_type_info.Test(eTypeIsPointer) &&
!root_compiler_type_info.Test(
eTypeIsVector)) // if this is not a T[] nor a T*
{
if (!root_compiler_type_info.Test(
eTypeIsScalar)) // if this is not even a scalar...
{
if (options.m_synthetic_children_traversal ==
GetValueForExpressionPathOptions::SyntheticChildrenTraversal::
None) // ...only chance left is synthetic
{
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonRangeOperatorInvalid;
*final_result = ValueObject::eExpressionPathEndResultTypeInvalid;
return ValueObjectSP();
}
} else if (!options.m_allow_bitfields_syntax) // if this is a scalar,
// check that we can
// expand bitfields
{
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonRangeOperatorNotAllowed;
*final_result = ValueObject::eExpressionPathEndResultTypeInvalid;
return ValueObjectSP();
}
}
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
if (temp_expression[1] ==
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
']') // if this is an unbounded range it only works for arrays
{
if (!root_compiler_type_info.Test(eTypeIsArray)) {
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonEmptyRangeNotAllowed;
*final_result = ValueObject::eExpressionPathEndResultTypeInvalid;
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
return nullptr;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
} else // even if something follows, we cannot expand unbounded ranges,
// just let the caller do it
{
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonArrayRangeOperatorMet;
*final_result =
ValueObject::eExpressionPathEndResultTypeUnboundedRange;
return root;
}
}
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
size_t close_bracket_position = temp_expression.find(']', 1);
if (close_bracket_position ==
llvm::StringRef::npos) // if there is no ], this is a syntax error
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
{
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonUnexpectedSymbol;
*final_result = ValueObject::eExpressionPathEndResultTypeInvalid;
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
return nullptr;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Remove some dead code in ValueObject. 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
2016-11-18 11:51:19 +08:00
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
llvm::StringRef bracket_expr =
temp_expression.slice(1, close_bracket_position);
// If this was an empty expression it would have been caught by the if
// above.
assert(!bracket_expr.empty());
if (!bracket_expr.contains('-')) {
Remove some dead code in ValueObject. 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
2016-11-18 11:51:19 +08:00
// if no separator, this is of the form [N]. Note that this cannot
// be an unbounded range of the form [], because that case was handled
// above with an unconditional return.
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
unsigned long index = 0;
if (bracket_expr.getAsInteger(0, index)) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonUnexpectedSymbol;
*final_result = ValueObject::eExpressionPathEndResultTypeInvalid;
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
return nullptr;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
// from here on we do have a valid index
if (root_compiler_type_info.Test(eTypeIsArray)) {
ValueObjectSP child_valobj_sp = root->GetChildAtIndex(index, true);
if (!child_valobj_sp)
child_valobj_sp = root->GetSyntheticArrayMember(index, true);
if (!child_valobj_sp)
if (root->HasSyntheticValue() &&
root->GetSyntheticValue()->GetNumChildren() > index)
child_valobj_sp =
root->GetSyntheticValue()->GetChildAtIndex(index, true);
if (child_valobj_sp) {
root = child_valobj_sp;
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
remainder =
temp_expression.substr(close_bracket_position + 1); // skip ]
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
*final_result = ValueObject::eExpressionPathEndResultTypePlain;
continue;
} else {
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonNoSuchChild;
*final_result = ValueObject::eExpressionPathEndResultTypeInvalid;
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
return nullptr;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
} else if (root_compiler_type_info.Test(eTypeIsPointer)) {
if (*what_next ==
ValueObject::
eExpressionPathAftermathDereference && // if this is a
// ptr-to-scalar, I
// am accessing it
// by index and I
// would have
// deref'ed anyway,
// then do it now
// and use this as
// a bitfield
pointee_compiler_type_info.Test(eTypeIsScalar)) {
Rename Error -> Status. 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
2017-05-12 12:51:55 +08:00
Status error;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
root = root->Dereference(error);
Re-add the StringRef interface changes for Variable. 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
2016-11-19 03:23:39 +08:00
if (error.Fail() || !root) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonDereferencingFailed;
*final_result = ValueObject::eExpressionPathEndResultTypeInvalid;
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
return nullptr;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
} else {
*what_next = eExpressionPathAftermathNothing;
continue;
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
} else {
if (root->GetCompilerType().GetMinimumLanguage() ==
eLanguageTypeObjC &&
pointee_compiler_type_info.AllClear(eTypeIsPointer) &&
root->HasSyntheticValue() &&
(options.m_synthetic_children_traversal ==
GetValueForExpressionPathOptions::
SyntheticChildrenTraversal::ToSynthetic ||
options.m_synthetic_children_traversal ==
GetValueForExpressionPathOptions::
SyntheticChildrenTraversal::Both)) {
root = root->GetSyntheticValue()->GetChildAtIndex(index, true);
} else
root = root->GetSyntheticArrayMember(index, true);
Re-add the StringRef interface changes for Variable. 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
2016-11-19 03:23:39 +08:00
if (!root) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonNoSuchChild;
*final_result = ValueObject::eExpressionPathEndResultTypeInvalid;
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
return nullptr;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
} else {
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
remainder =
temp_expression.substr(close_bracket_position + 1); // skip ]
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
*final_result = ValueObject::eExpressionPathEndResultTypePlain;
continue;
final fix for the global constructors issue new GetValueForExpressionPath() method in ValueObject to navigate expression paths in a more bitfield vs slices aware way changes to the varformats.html document (WIP) llvm-svn: 134679
2011-07-08 10:51:01 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
} else if (root_compiler_type_info.Test(eTypeIsScalar)) {
root = root->GetSyntheticBitFieldChild(index, index, true);
Re-add the StringRef interface changes for Variable. 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
2016-11-19 03:23:39 +08:00
if (!root) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonNoSuchChild;
*final_result = ValueObject::eExpressionPathEndResultTypeInvalid;
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
return nullptr;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
} else // we do not know how to expand members of bitfields, so we
// just return and let the caller do any further processing
{
*reason_to_stop = ValueObject::
eExpressionPathScanEndReasonBitfieldRangeOperatorMet;
*final_result = ValueObject::eExpressionPathEndResultTypeBitfield;
return root;
}
} else if (root_compiler_type_info.Test(eTypeIsVector)) {
root = root->GetChildAtIndex(index, true);
Re-add the StringRef interface changes for Variable. 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
2016-11-19 03:23:39 +08:00
if (!root) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonNoSuchChild;
*final_result = ValueObject::eExpressionPathEndResultTypeInvalid;
return ValueObjectSP();
} else {
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
remainder =
temp_expression.substr(close_bracket_position + 1); // skip ]
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
*final_result = ValueObject::eExpressionPathEndResultTypePlain;
continue;
}
} else if (options.m_synthetic_children_traversal ==
GetValueForExpressionPathOptions::
SyntheticChildrenTraversal::ToSynthetic ||
options.m_synthetic_children_traversal ==
GetValueForExpressionPathOptions::
SyntheticChildrenTraversal::Both) {
if (root->HasSyntheticValue())
root = root->GetSyntheticValue();
else if (!root->IsSynthetic()) {
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonSyntheticValueMissing;
*final_result = ValueObject::eExpressionPathEndResultTypeInvalid;
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
return nullptr;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
// if we are here, then root itself is a synthetic VO.. should be good
// to go
Re-add the StringRef interface changes for Variable. 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
2016-11-19 03:23:39 +08:00
if (!root) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonSyntheticValueMissing;
*final_result = ValueObject::eExpressionPathEndResultTypeInvalid;
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
return nullptr;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
root = root->GetChildAtIndex(index, true);
Re-add the StringRef interface changes for Variable. 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
2016-11-19 03:23:39 +08:00
if (!root) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonNoSuchChild;
*final_result = ValueObject::eExpressionPathEndResultTypeInvalid;
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
return nullptr;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
} else {
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
remainder =
temp_expression.substr(close_bracket_position + 1); // skip ]
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
*final_result = ValueObject::eExpressionPathEndResultTypePlain;
continue;
}
} else {
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonNoSuchChild;
*final_result = ValueObject::eExpressionPathEndResultTypeInvalid;
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
return nullptr;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
} else {
// we have a low and a high index
llvm::StringRef sleft, sright;
unsigned long low_index, high_index;
std::tie(sleft, sright) = bracket_expr.split('-');
if (sleft.getAsInteger(0, low_index) ||
sright.getAsInteger(0, high_index)) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonUnexpectedSymbol;
*final_result = ValueObject::eExpressionPathEndResultTypeInvalid;
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
return nullptr;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
if (low_index > high_index) // swap indices if required
std::swap(low_index, high_index);
Remove some dead code in ValueObject. 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
2016-11-18 11:51:19 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (root_compiler_type_info.Test(
eTypeIsScalar)) // expansion only works for scalars
{
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
root = root->GetSyntheticBitFieldChild(low_index, high_index, true);
Re-add the StringRef interface changes for Variable. 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
2016-11-19 03:23:39 +08:00
if (!root) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonNoSuchChild;
*final_result = ValueObject::eExpressionPathEndResultTypeInvalid;
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
return nullptr;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
} else {
*reason_to_stop = ValueObject::
eExpressionPathScanEndReasonBitfieldRangeOperatorMet;
*final_result = ValueObject::eExpressionPathEndResultTypeBitfield;
return root;
}
} else if (root_compiler_type_info.Test(
eTypeIsPointer) && // if this is a ptr-to-scalar, I am
// accessing it by index and I would
// have deref'ed anyway, then do it
// now and use this as a bitfield
*what_next ==
ValueObject::eExpressionPathAftermathDereference &&
pointee_compiler_type_info.Test(eTypeIsScalar)) {
Rename Error -> Status. 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
2017-05-12 12:51:55 +08:00
Status error;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
root = root->Dereference(error);
Re-add the StringRef interface changes for Variable. 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
2016-11-19 03:23:39 +08:00
if (error.Fail() || !root) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonDereferencingFailed;
*final_result = ValueObject::eExpressionPathEndResultTypeInvalid;
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
return nullptr;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
} else {
*what_next = ValueObject::eExpressionPathAftermathNothing;
continue;
}
} else {
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonArrayRangeOperatorMet;
*final_result = ValueObject::eExpressionPathEndResultTypeBoundedRange;
return root;
}
}
break;
}
default: // some non-separator is in the way
{
*reason_to_stop =
ValueObject::eExpressionPathScanEndReasonUnexpectedSymbol;
*final_result = ValueObject::eExpressionPathEndResultTypeInvalid;
Resubmit "Remove an output-parameter from Variable function". 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
2016-11-19 01:55:04 +08:00
return nullptr;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
}
}
}
void ValueObject::LogValueObject(Log *log) {
if (log)
return LogValueObject(log, DumpValueObjectOptions(*this));
}
void ValueObject::LogValueObject(Log *log,
const DumpValueObjectOptions &options) {
if (log) {
StreamString s;
Dump(s, options);
if (s.GetSize())
log->PutCString(s.GetData());
}
named summaries: - a new --name option for "type summary add" lets you give a name to a summary - a new --summary option for "frame variable" lets you bind a named summary to one or more variables ${var%s} now works for printing the value of 0-terminated CStrings type format test case now tests for cascading - this is disabled on GCC because GCC may end up stripping typedef chains, basically breaking cascading new design for the FormatNavigator class new template class CleanUp2 meant to support cleanup routines with 1 additional parameter beyond resource handle llvm-svn: 134943
2011-07-12 08:18:11 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
void ValueObject::Dump(Stream &s) { Dump(s, DumpValueObjectOptions(*this)); }
Added the ability to log a value object just as a value would be display when using the "frame variable" or "target variable" commands. llvm-svn: 153266
2012-03-23 02:15:37 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
void ValueObject::Dump(Stream &s, const DumpValueObjectOptions &options) {
ValueObjectPrinter printer(this, &s, options);
printer.PrintValueObject();
Added the ability to log a value object just as a value would be display when using the "frame variable" or "target variable" commands. llvm-svn: 153266
2012-03-23 02:15:37 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ValueObjectSP ValueObject::CreateConstantValue(const ConstString &name) {
ValueObjectSP valobj_sp;
1) solving a bug where, after Jim's fixes to stack frames, synthetic children were not recalculated when necessary, causing them to get out of sync with live data 2) providing an updated list of tagged pointers values for the objc_runtime module - hopefully this one is final 3) changing ValueObject::DumpValueObject to use an Options class instead of providing a bulky list of parameters to pass around this change had been laid out previously, but some clients of DumpValueObject() were still using the old prototype and some arguments were treated in a special way and passed in directly instead of through the Options class 4) providing new GetSummaryAsCString() and GetValueAsCString() calls in ValueObject that are passed a formatter object and a destination string and fill the string by formatting themselves using the formatter argument instead of the default for the current ValueObject 5) removing the option to have formats and summaries stick to a variable for the current stoppoint after some debate, we are going with non-sticky: if you say frame variable --format hex foo, the hex format will only be applied to the current command execution and not stick when redisplaying foo the other option would be full stickiness, which means that foo would be formatted as hex for its whole lifetime we are open to suggestions on what feels "natural" in this regard llvm-svn: 151801
2012-03-01 12:24:26 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (UpdateValueIfNeeded(false) && m_error.Success()) {
ExecutionContext exe_ctx(GetExecutionContextRef());
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
DataExtractor data;
data.SetByteOrder(m_data.GetByteOrder());
data.SetAddressByteSize(m_data.GetAddressByteSize());
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (IsBitfield()) {
Value v(Scalar(GetValueAsUnsigned(UINT64_MAX)));
m_error = v.GetValueAsData(&exe_ctx, data, 0, GetModule().get());
} else
m_error = m_value.GetValueAsData(&exe_ctx, data, 0, GetModule().get());
Add an API on ValueObject to retrieve the desired dynamic/synthetic combination all at once, if available, working somewhat hard to avoid returning an invalid ValueObject in the process llvm-svn: 219423
2014-10-10 02:24:30 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
valobj_sp = ValueObjectConstResult::Create(
exe_ctx.GetBestExecutionContextScope(), GetCompilerType(), name, data,
GetAddressOf());
}
LLDB now correctly handles virtual inheritance. Test case added as well. <rdar://problem/16785904> llvm-svn: 213433
2014-07-19 08:12:57 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (!valobj_sp) {
ExecutionContext exe_ctx(GetExecutionContextRef());
valobj_sp = ValueObjectConstResult::Create(
exe_ctx.GetBestExecutionContextScope(), m_error);
}
return valobj_sp;
LLDB now correctly handles virtual inheritance. Test case added as well. <rdar://problem/16785904> llvm-svn: 213433
2014-07-19 08:12:57 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ValueObjectSP ValueObject::GetQualifiedRepresentationIfAvailable(
lldb::DynamicValueType dynValue, bool synthValue) {
ValueObjectSP result_sp(GetSP());
Allow ValueObject::Dereference to dereference references. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11667 llvm-svn: 243716
2015-07-31 08:35:40 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
switch (dynValue) {
case lldb::eDynamicCanRunTarget:
case lldb::eDynamicDontRunTarget: {
if (!result_sp->IsDynamic()) {
if (result_sp->GetDynamicValue(dynValue))
result_sp = result_sp->GetDynamicValue(dynValue);
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
} break;
case lldb::eNoDynamicValues: {
if (result_sp->IsDynamic()) {
if (result_sp->GetStaticValue())
result_sp = result_sp->GetStaticValue();
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
} break;
}
Fixed the "expression" command object to use the StackFrame::GetValueForExpressionPath() function and also hooked up better error reporting for when things fail. Fixed issues with trying to display children of pointers when none are supposed to be shown (no children for function pointers, and more like this). This was causing child value objects to be made that were correctly firing an assertion. llvm-svn: 121841
2010-12-15 13:08:08 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (synthValue) {
if (!result_sp->IsSynthetic()) {
if (result_sp->GetSyntheticValue())
result_sp = result_sp->GetSyntheticValue();
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
} else {
if (result_sp->IsSynthetic()) {
if (result_sp->GetNonSyntheticValue())
result_sp = result_sp->GetNonSyntheticValue();
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Modified LLDB expressions to not have to JIT and run code just to see variable values or persistent expression variables. Now if an expression consists of a value that is a child of a variable, or of a persistent variable only, we will create a value object for it and make a ValueObjectConstResult from it to freeze the value (for program variables only, not persistent variables) and avoid running JITed code. For everything else we still parse up and JIT code and run it in the inferior. There was also a lot of clean up in the expression code. I made the ClangExpressionVariables be stored in collections of shared pointers instead of in collections of objects. This will help stop a lot of copy constructors on these large objects and also cleans up the code considerably. The persistent clang expression variables were moved over to the Target to ensure they persist across process executions. Added the ability for lldb_private::Target objects to evaluate expressions. We want to evaluate expressions at the target level in case we aren't running yet, or we have just completed running. We still want to be able to access the persistent expression variables between runs, and also evaluate constant expressions. Added extra logging to the dynamic loader plug-in for MacOSX. ModuleList objects can now dump their contents with the UUID, arch and full paths being logged with appropriate prefix values. Thread hardened the Communication class a bit by making the connection auto_ptr member into a shared pointer member and then making a local copy of the shared pointer in each method that uses it to make sure another thread can't nuke the connection object while it is being used by another thread. Added a new file to the lldb/test/load_unload test that causes the test a.out file to link to the libd.dylib file all the time. This will allow us to test using the DYLD_LIBRARY_PATH environment variable after moving libd.dylib somewhere else. llvm-svn: 121745
2010-12-14 10:59:59 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
return result_sp;
Fixed casting in the lldb::SBValue::Cast(SBType) function. llvm-svn: 149673
2012-02-03 13:34:10 +08:00
}
Added the ability to cast pointer types to another type, no matter what the ValueObject is, as long as the ValueObject that is being asked to be casted is a pointer itself. llvm-svn: 130966
2011-05-06 07:32:56 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
lldb::addr_t ValueObject::GetCPPVTableAddress(AddressType &address_type) {
CompilerType pointee_type;
CompilerType this_type(GetCompilerType());
uint32_t type_info = this_type.GetTypeInfo(&pointee_type);
if (type_info) {
bool ptr_or_ref = false;
if (type_info & (eTypeIsPointer | eTypeIsReference)) {
ptr_or_ref = true;
type_info = pointee_type.GetTypeInfo();
Added the ability to cast pointer types to another type, no matter what the ValueObject is, as long as the ValueObject that is being asked to be casted is a pointer itself. llvm-svn: 130966
2011-05-06 07:32:56 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
const uint32_t cpp_class = eTypeIsClass | eTypeIsCPlusPlus;
if ((type_info & cpp_class) == cpp_class) {
if (ptr_or_ref) {
address_type = GetAddressTypeOfChildren();
return GetValueAsUnsigned(LLDB_INVALID_ADDRESS);
} else
return GetAddressOf(false, &address_type);
Added the ability to cast pointer types to another type, no matter what the ValueObject is, as long as the ValueObject that is being asked to be casted is a pointer itself. llvm-svn: 130966
2011-05-06 07:32:56 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Added the ability to cast pointer types to another type, no matter what the ValueObject is, as long as the ValueObject that is being asked to be casted is a pointer itself. llvm-svn: 130966
2011-05-06 07:32:56 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
address_type = eAddressTypeInvalid;
return LLDB_INVALID_ADDRESS;
Convert ValueObject to explicitly maintain the Execution Context in which they were created, and then use that when they update themselves. That means all the ValueObject evaluate me type functions that used to require a Frame object now do not. I didn't remove the SBValue API's that take this now useless frame, but I added ones that don't require the frame, and marked the SBFrame taking ones as deprecated. llvm-svn: 128593
2011-03-31 08:19:25 +08:00
}
Rename Error -> Status. 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
2017-05-12 12:51:55 +08:00
ValueObjectSP ValueObject::Dereference(Status &error) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (m_deref_valobj)
return m_deref_valobj->GetSP();
const bool is_pointer_or_reference_type = IsPointerOrReferenceType();
if (is_pointer_or_reference_type) {
bool omit_empty_base_classes = true;
bool ignore_array_bounds = false;
std::string child_name_str;
uint32_t child_byte_size = 0;
int32_t child_byte_offset = 0;
uint32_t child_bitfield_bit_size = 0;
uint32_t child_bitfield_bit_offset = 0;
bool child_is_base_class = false;
bool child_is_deref_of_parent = false;
const bool transparent_pointers = false;
CompilerType compiler_type = GetCompilerType();
CompilerType child_compiler_type;
uint64_t language_flags;
ExecutionContext exe_ctx(GetExecutionContextRef());
child_compiler_type = compiler_type.GetChildCompilerTypeAtIndex(
&exe_ctx, 0, transparent_pointers, omit_empty_base_classes,
ignore_array_bounds, child_name_str, child_byte_size, child_byte_offset,
child_bitfield_bit_size, child_bitfield_bit_offset, child_is_base_class,
child_is_deref_of_parent, this, language_flags);
if (child_compiler_type && child_byte_size) {
ConstString child_name;
if (!child_name_str.empty())
child_name.SetCString(child_name_str.c_str());
m_deref_valobj = new ValueObjectChild(
*this, child_compiler_type, child_name, child_byte_size,
child_byte_offset, child_bitfield_bit_size, child_bitfield_bit_offset,
child_is_base_class, child_is_deref_of_parent, eAddressTypeInvalid,
language_flags);
Convert ValueObject to explicitly maintain the Execution Context in which they were created, and then use that when they update themselves. That means all the ValueObject evaluate me type functions that used to require a Frame object now do not. I didn't remove the SBValue API's that take this now useless frame, but I added ones that don't require the frame, and marked the SBFrame taking ones as deprecated. llvm-svn: 128593
2011-03-31 08:19:25 +08:00
}
Add support for sythetic operator dereference 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
2017-04-01 04:23:22 +08:00
} else if (HasSyntheticValue()) {
m_deref_valobj =
GetSyntheticValue()
->GetChildMemberWithName(ConstString("$$dereference$$"), true)
.get();
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
Convert ValueObject to explicitly maintain the Execution Context in which they were created, and then use that when they update themselves. That means all the ValueObject evaluate me type functions that used to require a Frame object now do not. I didn't remove the SBValue API's that take this now useless frame, but I added ones that don't require the frame, and marked the SBFrame taking ones as deprecated. llvm-svn: 128593
2011-03-31 08:19:25 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (m_deref_valobj) {
error.Clear();
return m_deref_valobj->GetSP();
} else {
StreamString strm;
GetExpressionPath(strm, true);
Convert ValueObject to explicitly maintain the Execution Context in which they were created, and then use that when they update themselves. That means all the ValueObject evaluate me type functions that used to require a Frame object now do not. I didn't remove the SBValue API's that take this now useless frame, but I added ones that don't require the frame, and marked the SBFrame taking ones as deprecated. llvm-svn: 128593
2011-03-31 08:19:25 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (is_pointer_or_reference_type)
error.SetErrorStringWithFormat("dereference failed: (%s) %s",
GetTypeName().AsCString("<invalid type>"),
Don't allow direct access to StreamString's internal buffer. 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
2016-11-17 05:15:24 +08:00
strm.GetData());
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
else
error.SetErrorStringWithFormat("not a pointer or reference type: (%s) %s",
GetTypeName().AsCString("<invalid type>"),
Don't allow direct access to StreamString's internal buffer. 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
2016-11-17 05:15:24 +08:00
strm.GetData());
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
return ValueObjectSP();
}
Convert ValueObject to explicitly maintain the Execution Context in which they were created, and then use that when they update themselves. That means all the ValueObject evaluate me type functions that used to require a Frame object now do not. I didn't remove the SBValue API's that take this now useless frame, but I added ones that don't require the frame, and marked the SBFrame taking ones as deprecated. llvm-svn: 128593
2011-03-31 08:19:25 +08:00
}
Rename Error -> Status. 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
2017-05-12 12:51:55 +08:00
ValueObjectSP ValueObject::AddressOf(Status &error) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (m_addr_of_valobj_sp)
return m_addr_of_valobj_sp;
AddressType address_type = eAddressTypeInvalid;
const bool scalar_is_load_address = false;
addr_t addr = GetAddressOf(scalar_is_load_address, &address_type);
error.Clear();
if (addr != LLDB_INVALID_ADDRESS && address_type != eAddressTypeHost) {
switch (address_type) {
case eAddressTypeInvalid: {
StreamString expr_path_strm;
GetExpressionPath(expr_path_strm, true);
error.SetErrorStringWithFormat("'%s' is not in memory",
Don't allow direct access to StreamString's internal buffer. 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
2016-11-17 05:15:24 +08:00
expr_path_strm.GetData());
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
} break;
case eAddressTypeFile:
case eAddressTypeLoad: {
CompilerType compiler_type = GetCompilerType();
if (compiler_type) {
std::string name(1, '&');
name.append(m_name.AsCString(""));
ExecutionContext exe_ctx(GetExecutionContextRef());
m_addr_of_valobj_sp = ValueObjectConstResult::Create(
exe_ctx.GetBestExecutionContextScope(),
compiler_type.GetPointerType(), ConstString(name.c_str()), addr,
eAddressTypeInvalid, m_data.GetAddressByteSize());
}
} break;
default:
break;
}
} else {
StreamString expr_path_strm;
GetExpressionPath(expr_path_strm, true);
error.SetErrorStringWithFormat("'%s' doesn't have a valid address",
Don't allow direct access to StreamString's internal buffer. 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
2016-11-17 05:15:24 +08:00
expr_path_strm.GetData());
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
return m_addr_of_valobj_sp;
}
ValueObjectSP ValueObject::Cast(const CompilerType &compiler_type) {
return ValueObjectCast::Create(*this, GetName(), compiler_type);
}
Stop calling ValueObject::SetName from synthetic child providers 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
2017-04-01 04:48:00 +08:00
lldb::ValueObjectSP ValueObject::Clone(const ConstString &new_name) {
return ValueObjectCast::Create(*this, new_name, GetCompilerType());
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ValueObjectSP ValueObject::CastPointerType(const char *name,
CompilerType &compiler_type) {
ValueObjectSP valobj_sp;
AddressType address_type;
addr_t ptr_value = GetPointerValue(&address_type);
if (ptr_value != LLDB_INVALID_ADDRESS) {
Address ptr_addr(ptr_value);
ExecutionContext exe_ctx(GetExecutionContextRef());
valobj_sp = ValueObjectMemory::Create(
exe_ctx.GetBestExecutionContextScope(), name, ptr_addr, compiler_type);
}
return valobj_sp;
}
ValueObjectSP ValueObject::CastPointerType(const char *name, TypeSP &type_sp) {
ValueObjectSP valobj_sp;
AddressType address_type;
addr_t ptr_value = GetPointerValue(&address_type);
if (ptr_value != LLDB_INVALID_ADDRESS) {
Address ptr_addr(ptr_value);
ExecutionContext exe_ctx(GetExecutionContextRef());
valobj_sp = ValueObjectMemory::Create(
exe_ctx.GetBestExecutionContextScope(), name, ptr_addr, type_sp);
}
return valobj_sp;
}
ValueObject::EvaluationPoint::EvaluationPoint()
: m_mod_id(), m_exe_ctx_ref(), m_needs_update(true) {}
ValueObject::EvaluationPoint::EvaluationPoint(ExecutionContextScope *exe_scope,
bool use_selected)
: m_mod_id(), m_exe_ctx_ref(), m_needs_update(true) {
ExecutionContext exe_ctx(exe_scope);
TargetSP target_sp(exe_ctx.GetTargetSP());
if (target_sp) {
m_exe_ctx_ref.SetTargetSP(target_sp);
ProcessSP process_sp(exe_ctx.GetProcessSP());
if (!process_sp)
process_sp = target_sp->GetProcessSP();
if (process_sp) {
m_mod_id = process_sp->GetModID();
m_exe_ctx_ref.SetProcessSP(process_sp);
ThreadSP thread_sp(exe_ctx.GetThreadSP());
if (!thread_sp) {
if (use_selected)
thread_sp = process_sp->GetThreadList().GetSelectedThread();
}
if (thread_sp) {
m_exe_ctx_ref.SetThreadSP(thread_sp);
StackFrameSP frame_sp(exe_ctx.GetFrameSP());
if (!frame_sp) {
if (use_selected)
frame_sp = thread_sp->GetSelectedFrame();
}
if (frame_sp)
m_exe_ctx_ref.SetFrameSP(frame_sp);
}
}
}
}
ValueObject::EvaluationPoint::EvaluationPoint(
const ValueObject::EvaluationPoint &rhs)
: m_mod_id(), m_exe_ctx_ref(rhs.m_exe_ctx_ref), m_needs_update(true) {}
ValueObject::EvaluationPoint::~EvaluationPoint() {}
// This function checks the EvaluationPoint against the current process state.
// If the current
// state matches the evaluation point, or the evaluation point is already
// invalid, then we return
// false, meaning "no change". If the current state is different, we update our
// state, and return
// true meaning "yes, change". If we did see a change, we also set
// m_needs_update to true, so
Convert ValueObject to explicitly maintain the Execution Context in which they were created, and then use that when they update themselves. That means all the ValueObject evaluate me type functions that used to require a Frame object now do not. I didn't remove the SBValue API's that take this now useless frame, but I added ones that don't require the frame, and marked the SBFrame taking ones as deprecated. llvm-svn: 128593
2011-03-31 08:19:25 +08:00
// future calls to NeedsUpdate will return true.
Don't try to cache the ExecutionContextScope in the ValueObject::EvaluationPoint, it is too hard to ensure it doesn't get invalidated out from under us. Instead look it up from the ThreadID and StackID when asked for it. <rdar://problem/10554409> llvm-svn: 146309
2011-12-10 09:49:43 +08:00
// exe_scope will be set to the current execution context scope.
Convert ValueObject to explicitly maintain the Execution Context in which they were created, and then use that when they update themselves. That means all the ValueObject evaluate me type functions that used to require a Frame object now do not. I didn't remove the SBValue API's that take this now useless frame, but I added ones that don't require the frame, and marked the SBFrame taking ones as deprecated. llvm-svn: 128593
2011-03-31 08:19:25 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
bool ValueObject::EvaluationPoint::SyncWithProcessState(
bool accept_invalid_exe_ctx) {
// Start with the target, if it is NULL, then we're obviously not going to get
// any further:
const bool thread_and_frame_only_if_stopped = true;
ExecutionContext exe_ctx(
m_exe_ctx_ref.Lock(thread_and_frame_only_if_stopped));
Constant result ValueObjects are - well - constant 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
2015-05-16 09:27:00 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (exe_ctx.GetTargetPtr() == NULL)
return false;
Convert ValueObject to explicitly maintain the Execution Context in which they were created, and then use that when they update themselves. That means all the ValueObject evaluate me type functions that used to require a Frame object now do not. I didn't remove the SBValue API's that take this now useless frame, but I added ones that don't require the frame, and marked the SBFrame taking ones as deprecated. llvm-svn: 128593
2011-03-31 08:19:25 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
// If we don't have a process nothing can change.
Process *process = exe_ctx.GetProcessPtr();
if (process == NULL)
return false;
Redesign of the interaction between Python and frozen objects: - introduced two new classes ValueObjectConstResultChild and ValueObjectConstResultImpl: the first one is a ValueObjectChild obtained from a ValueObjectConstResult, the second is a common implementation backend for VOCR and VOCRCh of method calls meant to read through pointers stored in frozen objects ; now such reads transparently move from host to target as required - as a consequence of the above, removed code that made target-memory copies of expression results in several places throughout LLDB, and also removed code that enabled to recognize an expression result VO as such - introduced a new GetPointeeData() method in ValueObject that lets you read a given amount of objects of type T from a VO representing a T* or T[], and doing dereferences transparently in private layer it returns a DataExtractor ; in public layer it returns an instance of a newly created lldb::SBData - as GetPointeeData() does the right thing for both frozen and non-frozen ValueObject's, reimplemented ReadPointedString() to use it en lieu of doing the raw read itself - introduced a new GetData() method in ValueObject that lets you get a copy of the data that backs the ValueObject (for pointers, this returns the address without any previous dereferencing steps ; for arrays it actually reads the whole chunk of memory) in public layer this returns an SBData, just like GetPointeeData() - introduced a new CreateValueFromData() method in SBValue that lets you create a new SBValue from a chunk of data wrapped in an SBData the limitation to remember for this kind of SBValue is that they have no address: extracting the address-of for these objects (with any of GetAddress(), GetLoadAddress() and AddressOf()) will return invalid values - added several tests to check that "p"-ing objects (STL classes, char* and char[]) will do the right thing Solved a bug where global pointers to global variables were not dereferenced correctly for display New target setting "max-string-summary-length" gives the maximum number of characters to show in a string when summarizing it, instead of the hardcoded 128 Solved a bug where the summary for char[] and char* would not be shown if the ValueObject's were dumped via the "p" command Removed m_pointers_point_to_load_addrs from ValueObject. Introduced a new m_address_type_of_children, which each ValueObject can set to tell the address type of any pointers and/or references it creates. In the current codebase, this is load address most of the time (the only notable exception being file addresses that generate file address children UNLESS we have a live process) Updated help text for summary-string Fixed an issue in STL formatters where std::stlcontainer::iterator would match the container's synthetic children providers Edited the syntax and help for some commands to have proper argument types llvm-svn: 139160
2011-09-07 03:20:51 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
// If our stop id is the current stop ID, nothing has changed:
ProcessModID current_mod_id = process->GetModID();
<rdar://problem/11086338> Implementing support for synthetic children generated by running C++ code instead of Python scripts ; Adding a bunch of value-generating APIs to our private code layer ; Providing synthetic children for NSArray llvm-svn: 163818
2012-09-14 02:27:09 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
// If the current stop id is 0, either we haven't run yet, or the process
// state has been cleared.
// In either case, we aren't going to be able to sync with the process state.
if (current_mod_id.GetStopID() == 0)
return false;
bool changed = false;
const bool was_valid = m_mod_id.IsValid();
if (was_valid) {
if (m_mod_id == current_mod_id) {
// Everything is already up to date in this object, no need to
// update the execution context scope.
changed = false;
} else {
m_mod_id = current_mod_id;
m_needs_update = true;
changed = true;
}
}
// Now re-look up the thread and frame in case the underlying objects have
// gone away & been recreated.
// That way we'll be sure to return a valid exe_scope.
// If we used to have a thread or a frame but can't find it anymore, then mark
// ourselves as invalid.
if (!accept_invalid_exe_ctx) {
if (m_exe_ctx_ref.HasThreadRef()) {
ThreadSP thread_sp(m_exe_ctx_ref.GetThreadSP());
if (thread_sp) {
if (m_exe_ctx_ref.HasFrameRef()) {
StackFrameSP frame_sp(m_exe_ctx_ref.GetFrameSP());
if (!frame_sp) {
// We used to have a frame, but now it is gone
SetInvalid();
changed = was_valid;
}
}
} else {
// We used to have a thread, but now it is gone
SetInvalid();
changed = was_valid;
}
}
}
return changed;
}
void ValueObject::EvaluationPoint::SetUpdated() {
ProcessSP process_sp(m_exe_ctx_ref.GetProcessSP());
if (process_sp)
m_mod_id = process_sp->GetModID();
m_needs_update = false;
}
void ValueObject::ClearUserVisibleData(uint32_t clear_mask) {
if ((clear_mask & eClearUserVisibleDataItemsValue) ==
eClearUserVisibleDataItemsValue)
m_value_str.clear();
if ((clear_mask & eClearUserVisibleDataItemsLocation) ==
eClearUserVisibleDataItemsLocation)
m_location_str.clear();
if ((clear_mask & eClearUserVisibleDataItemsSummary) ==
eClearUserVisibleDataItemsSummary)
m_summary_str.clear();
if ((clear_mask & eClearUserVisibleDataItemsDescription) ==
eClearUserVisibleDataItemsDescription)
m_object_desc_str.clear();
if ((clear_mask & eClearUserVisibleDataItemsSyntheticChildren) ==
eClearUserVisibleDataItemsSyntheticChildren) {
if (m_synthetic_value)
m_synthetic_value = NULL;
}
if ((clear_mask & eClearUserVisibleDataItemsValidator) ==
eClearUserVisibleDataItemsValidator)
m_validation_result.reset();
Provide CreateValueFromData,Expression at the SBTarget level as well as the SBValue level; and also make all the implenentations agree on using the matching ValueObject::Create instead of doing code copypastas llvm-svn: 224460
2014-12-18 05:18:43 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
SymbolContextScope *ValueObject::GetSymbolContextScope() {
if (m_parent) {
if (!m_parent->IsPointerOrReferenceType())
return m_parent->GetSymbolContextScope();
}
return NULL;
}
Provide CreateValueFromData,Expression at the SBTarget level as well as the SBValue level; and also make all the implenentations agree on using the matching ValueObject::Create instead of doing code copypastas llvm-svn: 224460
2014-12-18 05:18:43 +08:00
Change ValueObject creation functions to take StringRefs. llvm-svn: 286744
2016-11-13 11:29:46 +08:00
lldb::ValueObjectSP
ValueObject::CreateValueObjectFromExpression(llvm::StringRef name,
llvm::StringRef expression,
const ExecutionContext &exe_ctx) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
return CreateValueObjectFromExpression(name, expression, exe_ctx,
EvaluateExpressionOptions());
<rdar://problem/11086338> Implementing support for synthetic children generated by running C++ code instead of Python scripts ; Adding a bunch of value-generating APIs to our private code layer ; Providing synthetic children for NSArray llvm-svn: 163818
2012-09-14 02:27:09 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
lldb::ValueObjectSP ValueObject::CreateValueObjectFromExpression(
Change ValueObject creation functions to take StringRefs. llvm-svn: 286744
2016-11-13 11:29:46 +08:00
llvm::StringRef name, llvm::StringRef expression,
const ExecutionContext &exe_ctx, const EvaluateExpressionOptions &options) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
lldb::ValueObjectSP retval_sp;
lldb::TargetSP target_sp(exe_ctx.GetTargetSP());
if (!target_sp)
return retval_sp;
Change ValueObject creation functions to take StringRefs. llvm-svn: 286744
2016-11-13 11:29:46 +08:00
if (expression.empty())
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
return retval_sp;
target_sp->EvaluateExpression(expression, exe_ctx.GetFrameSP().get(),
retval_sp, options);
Change ValueObject creation functions to take StringRefs. llvm-svn: 286744
2016-11-13 11:29:46 +08:00
if (retval_sp && !name.empty())
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
retval_sp->SetName(ConstString(name));
return retval_sp;
<rdar://problem/11086338> Implementing support for synthetic children generated by running C++ code instead of Python scripts ; Adding a bunch of value-generating APIs to our private code layer ; Providing synthetic children for NSArray llvm-svn: 163818
2012-09-14 02:27:09 +08:00
}
Change ValueObject creation functions to take StringRefs. llvm-svn: 286744
2016-11-13 11:29:46 +08:00
lldb::ValueObjectSP ValueObject::CreateValueObjectFromAddress(
llvm::StringRef name, uint64_t address, const ExecutionContext &exe_ctx,
CompilerType type) {
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (type) {
CompilerType pointer_type(type.GetPointerType());
if (pointer_type) {
lldb::DataBufferSP buffer(
new lldb_private::DataBufferHeap(&address, sizeof(lldb::addr_t)));
lldb::ValueObjectSP ptr_result_valobj_sp(ValueObjectConstResult::Create(
exe_ctx.GetBestExecutionContextScope(), pointer_type,
ConstString(name), buffer, exe_ctx.GetByteOrder(),
exe_ctx.GetAddressByteSize()));
if (ptr_result_valobj_sp) {
ptr_result_valobj_sp->GetValue().SetValueType(
Value::eValueTypeLoadAddress);
Rename Error -> Status. 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
2017-05-12 12:51:55 +08:00
Status err;
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ptr_result_valobj_sp = ptr_result_valobj_sp->Dereference(err);
Change ValueObject creation functions to take StringRefs. llvm-svn: 286744
2016-11-13 11:29:46 +08:00
if (ptr_result_valobj_sp && !name.empty())
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ptr_result_valobj_sp->SetName(ConstString(name));
}
return ptr_result_valobj_sp;
}
}
return lldb::ValueObjectSP();
}
lldb::ValueObjectSP ValueObject::CreateValueObjectFromData(
Change ValueObject creation functions to take StringRefs. llvm-svn: 286744
2016-11-13 11:29:46 +08:00
llvm::StringRef name, const DataExtractor &data,
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
const ExecutionContext &exe_ctx, CompilerType type) {
lldb::ValueObjectSP new_value_sp;
new_value_sp = ValueObjectConstResult::Create(
exe_ctx.GetBestExecutionContextScope(), type, ConstString(name), data,
LLDB_INVALID_ADDRESS);
new_value_sp->SetAddressTypeOfChildren(eAddressTypeLoad);
Change ValueObject creation functions to take StringRefs. llvm-svn: 286744
2016-11-13 11:29:46 +08:00
if (new_value_sp && !name.empty())
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
new_value_sp->SetName(ConstString(name));
return new_value_sp;
}
ModuleSP ValueObject::GetModule() {
ValueObject *root(GetRoot());
if (root != this)
return root->GetModule();
return lldb::ModuleSP();
}
ValueObject *ValueObject::GetRoot() {
if (m_root)
return m_root;
return (m_root = FollowParentChain([](ValueObject *vo) -> bool {
return (vo->m_parent != nullptr);
}));
<rdar://problem/11086338> Implementing support for synthetic children generated by running C++ code instead of Python scripts ; Adding a bunch of value-generating APIs to our private code layer ; Providing synthetic children for NSArray llvm-svn: 163818
2012-09-14 02:27:09 +08:00
}
<rdar://problem/13623698> This patch fixes the issue that we were using the C stack as a measure of depth of ValueObject hierarchies, in the sense that we were assuming that recursive ValueObject operations would never be deeper than the stack allows. This assumption is easy to prove wrong, however. For instance, after ~10k runs through this loop: struct node { int value; node* child; node (int x) { value = x; child = nullptr; } }; int main () { node root(1); node* ptr = &root; int j = 2; while (1) { ptr->child = new node(j++); ptr = ptr->child; } return 0; } the deepmost child object will be deeper than the stack on most architectures, and we would be unable to display it This checkin fixes the issue by introducing a notion of root of ValueObject hierarchies. In a couple cases, we have to use an iterative algorithm instead of going to the root because we want to allow deeper customizations (e.g. formats, dynamic values). While the patch passes our test suite without regressions, it is a good idea to keep eyes open for any unexpected behavior (recursion can be subtle..) Also, I am hesitant to introduce a test case since failing at this will not just be marked as an "F", but most definitely crash LLDB. llvm-svn: 179330
2013-04-12 06:48:58 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ValueObject *
ValueObject::FollowParentChain(std::function<bool(ValueObject *)> f) {
ValueObject *vo = this;
while (vo) {
if (f(vo) == false)
break;
vo = vo->m_parent;
}
return vo;
}
AddressType ValueObject::GetAddressTypeOfChildren() {
if (m_address_type_of_ptr_or_ref_children == eAddressTypeInvalid) {
ValueObject *root(GetRoot());
<rdar://problem/13623698> This patch fixes the issue that we were using the C stack as a measure of depth of ValueObject hierarchies, in the sense that we were assuming that recursive ValueObject operations would never be deeper than the stack allows. This assumption is easy to prove wrong, however. For instance, after ~10k runs through this loop: struct node { int value; node* child; node (int x) { value = x; child = nullptr; } }; int main () { node root(1); node* ptr = &root; int j = 2; while (1) { ptr->child = new node(j++); ptr = ptr->child; } return 0; } the deepmost child object will be deeper than the stack on most architectures, and we would be unable to display it This checkin fixes the issue by introducing a notion of root of ValueObject hierarchies. In a couple cases, we have to use an iterative algorithm instead of going to the root because we want to allow deeper customizations (e.g. formats, dynamic values). While the patch passes our test suite without regressions, it is a good idea to keep eyes open for any unexpected behavior (recursion can be subtle..) Also, I am hesitant to introduce a test case since failing at this will not just be marked as an "F", but most definitely crash LLDB. llvm-svn: 179330
2013-04-12 06:48:58 +08:00
if (root != this)
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
return root->GetAddressTypeOfChildren();
}
return m_address_type_of_ptr_or_ref_children;
<rdar://problem/13623698> This patch fixes the issue that we were using the C stack as a measure of depth of ValueObject hierarchies, in the sense that we were assuming that recursive ValueObject operations would never be deeper than the stack allows. This assumption is easy to prove wrong, however. For instance, after ~10k runs through this loop: struct node { int value; node* child; node (int x) { value = x; child = nullptr; } }; int main () { node root(1); node* ptr = &root; int j = 2; while (1) { ptr->child = new node(j++); ptr = ptr->child; } return 0; } the deepmost child object will be deeper than the stack on most architectures, and we would be unable to display it This checkin fixes the issue by introducing a notion of root of ValueObject hierarchies. In a couple cases, we have to use an iterative algorithm instead of going to the root because we want to allow deeper customizations (e.g. formats, dynamic values). While the patch passes our test suite without regressions, it is a good idea to keep eyes open for any unexpected behavior (recursion can be subtle..) Also, I am hesitant to introduce a test case since failing at this will not just be marked as an "F", but most definitely crash LLDB. llvm-svn: 179330
2013-04-12 06:48:58 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
lldb::DynamicValueType ValueObject::GetDynamicValueType() {
ValueObject *with_dv_info = this;
while (with_dv_info) {
if (with_dv_info->HasDynamicValueTypeInfo())
return with_dv_info->GetDynamicValueTypeImpl();
with_dv_info = with_dv_info->m_parent;
}
return lldb::eNoDynamicValues;
Add an API to ValueObject that iterates over the entire parent chain via a callback, and rewrite GetRoot() in terms of this general iteration API. NFC llvm-svn: 226771
2015-01-22 11:07:34 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
lldb::Format ValueObject::GetFormat() const {
const ValueObject *with_fmt_info = this;
while (with_fmt_info) {
if (with_fmt_info->m_format != lldb::eFormatDefault)
return with_fmt_info->m_format;
with_fmt_info = with_fmt_info->m_parent;
}
return m_format;
<rdar://problem/13623698> This patch fixes the issue that we were using the C stack as a measure of depth of ValueObject hierarchies, in the sense that we were assuming that recursive ValueObject operations would never be deeper than the stack allows. This assumption is easy to prove wrong, however. For instance, after ~10k runs through this loop: struct node { int value; node* child; node (int x) { value = x; child = nullptr; } }; int main () { node root(1); node* ptr = &root; int j = 2; while (1) { ptr->child = new node(j++); ptr = ptr->child; } return 0; } the deepmost child object will be deeper than the stack on most architectures, and we would be unable to display it This checkin fixes the issue by introducing a notion of root of ValueObject hierarchies. In a couple cases, we have to use an iterative algorithm instead of going to the root because we want to allow deeper customizations (e.g. formats, dynamic values). While the patch passes our test suite without regressions, it is a good idea to keep eyes open for any unexpected behavior (recursion can be subtle..) Also, I am hesitant to introduce a test case since failing at this will not just be marked as an "F", but most definitely crash LLDB. llvm-svn: 179330
2013-04-12 06:48:58 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
lldb::LanguageType ValueObject::GetPreferredDisplayLanguage() {
lldb::LanguageType type = m_preferred_display_language;
if (m_preferred_display_language == lldb::eLanguageTypeUnknown) {
if (GetRoot()) {
if (GetRoot() == this) {
if (StackFrameSP frame_sp = GetFrameSP()) {
const SymbolContext &sc(
frame_sp->GetSymbolContext(eSymbolContextCompUnit));
if (CompileUnit *cu = sc.comp_unit)
type = cu->GetLanguage();
}
} else {
type = GetRoot()->GetPreferredDisplayLanguage();
}
<rdar://problem/13623698> This patch fixes the issue that we were using the C stack as a measure of depth of ValueObject hierarchies, in the sense that we were assuming that recursive ValueObject operations would never be deeper than the stack allows. This assumption is easy to prove wrong, however. For instance, after ~10k runs through this loop: struct node { int value; node* child; node (int x) { value = x; child = nullptr; } }; int main () { node root(1); node* ptr = &root; int j = 2; while (1) { ptr->child = new node(j++); ptr = ptr->child; } return 0; } the deepmost child object will be deeper than the stack on most architectures, and we would be unable to display it This checkin fixes the issue by introducing a notion of root of ValueObject hierarchies. In a couple cases, we have to use an iterative algorithm instead of going to the root because we want to allow deeper customizations (e.g. formats, dynamic values). While the patch passes our test suite without regressions, it is a good idea to keep eyes open for any unexpected behavior (recursion can be subtle..) Also, I am hesitant to introduce a test case since failing at this will not just be marked as an "F", but most definitely crash LLDB. llvm-svn: 179330
2013-04-12 06:48:58 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
}
return (m_preferred_display_language = type); // only compute it once
<rdar://problem/13623698> This patch fixes the issue that we were using the C stack as a measure of depth of ValueObject hierarchies, in the sense that we were assuming that recursive ValueObject operations would never be deeper than the stack allows. This assumption is easy to prove wrong, however. For instance, after ~10k runs through this loop: struct node { int value; node* child; node (int x) { value = x; child = nullptr; } }; int main () { node root(1); node* ptr = &root; int j = 2; while (1) { ptr->child = new node(j++); ptr = ptr->child; } return 0; } the deepmost child object will be deeper than the stack on most architectures, and we would be unable to display it This checkin fixes the issue by introducing a notion of root of ValueObject hierarchies. In a couple cases, we have to use an iterative algorithm instead of going to the root because we want to allow deeper customizations (e.g. formats, dynamic values). While the patch passes our test suite without regressions, it is a good idea to keep eyes open for any unexpected behavior (recursion can be subtle..) Also, I am hesitant to introduce a test case since failing at this will not just be marked as an "F", but most definitely crash LLDB. llvm-svn: 179330
2013-04-12 06:48:58 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
void ValueObject::SetPreferredDisplayLanguage(lldb::LanguageType lt) {
m_preferred_display_language = lt;
<rdar://problem/13623698> This patch fixes the issue that we were using the C stack as a measure of depth of ValueObject hierarchies, in the sense that we were assuming that recursive ValueObject operations would never be deeper than the stack allows. This assumption is easy to prove wrong, however. For instance, after ~10k runs through this loop: struct node { int value; node* child; node (int x) { value = x; child = nullptr; } }; int main () { node root(1); node* ptr = &root; int j = 2; while (1) { ptr->child = new node(j++); ptr = ptr->child; } return 0; } the deepmost child object will be deeper than the stack on most architectures, and we would be unable to display it This checkin fixes the issue by introducing a notion of root of ValueObject hierarchies. In a couple cases, we have to use an iterative algorithm instead of going to the root because we want to allow deeper customizations (e.g. formats, dynamic values). While the patch passes our test suite without regressions, it is a good idea to keep eyes open for any unexpected behavior (recursion can be subtle..) Also, I am hesitant to introduce a test case since failing at this will not just be marked as an "F", but most definitely crash LLDB. llvm-svn: 179330
2013-04-12 06:48:58 +08:00
}
Small code cleanups llvm-svn: 183024
2013-06-01 01:43:40 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
void ValueObject::SetPreferredDisplayLanguageIfNeeded(lldb::LanguageType lt) {
if (m_preferred_display_language == lldb::eLanguageTypeUnknown)
SetPreferredDisplayLanguage(lt);
<rdar://problem/13623698> This patch fixes the issue that we were using the C stack as a measure of depth of ValueObject hierarchies, in the sense that we were assuming that recursive ValueObject operations would never be deeper than the stack allows. This assumption is easy to prove wrong, however. For instance, after ~10k runs through this loop: struct node { int value; node* child; node (int x) { value = x; child = nullptr; } }; int main () { node root(1); node* ptr = &root; int j = 2; while (1) { ptr->child = new node(j++); ptr = ptr->child; } return 0; } the deepmost child object will be deeper than the stack on most architectures, and we would be unable to display it This checkin fixes the issue by introducing a notion of root of ValueObject hierarchies. In a couple cases, we have to use an iterative algorithm instead of going to the root because we want to allow deeper customizations (e.g. formats, dynamic values). While the patch passes our test suite without regressions, it is a good idea to keep eyes open for any unexpected behavior (recursion can be subtle..) Also, I am hesitant to introduce a test case since failing at this will not just be marked as an "F", but most definitely crash LLDB. llvm-svn: 179330
2013-04-12 06:48:58 +08:00
}
Extend synthetic children to produce synthetic values (as in, those that 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
2014-10-09 02:27:36 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
bool ValueObject::CanProvideValue() {
// we need to support invalid types as providers of values because some
// bare-board
// debugging scenarios have no notion of types, but still manage to have raw
// numeric
// values for things like registers. sigh.
const CompilerType &type(GetCompilerType());
return (false == type.IsValid()) ||
(0 != (type.GetTypeInfo() & eTypeHasValue));
Allow individual ValueObjects to pick their preferred display language 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
2015-01-21 09:47:13 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
bool ValueObject::IsChecksumEmpty() { return m_value_checksum.empty(); }
Introduce the notion of "type summary options" as flags that can be passed 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
2014-11-07 05:23:20 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ValueObjectSP ValueObject::Persist() {
if (!UpdateValueIfNeeded())
return nullptr;
Route the preferred-display-language mechanism to the ValueObjectPrinter and actually fill in a few gaps for dynamic and synthetic values to be able to adopt this in useful ways llvm-svn: 249507
2015-10-07 10:36:35 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
TargetSP target_sp(GetTargetSP());
if (!target_sp)
return nullptr;
Fixed ValueObject::UpdateValueIfNeeded to keep 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
2014-12-10 05:18:59 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
PersistentExpressionState *persistent_state =
target_sp->GetPersistentExpressionStateForLanguage(
GetPreferredDisplayLanguage());
Add the ability for an SBValue to create a persisted version of itself. 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
2014-12-09 07:13:56 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
if (!persistent_state)
return nullptr;
This patch does a few things: - 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
2014-12-10 03:51:20 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ConstString name(persistent_state->GetNextPersistentVariableName());
This patch does a few things: - 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
2014-12-10 03:51:20 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
ValueObjectSP const_result_sp =
ValueObjectConstResult::Create(target_sp.get(), GetValue(), name);
ExpressionVariableSP clang_var_sp =
persistent_state->CreatePersistentVariable(const_result_sp);
clang_var_sp->m_live_sp = clang_var_sp->m_frozen_sp;
clang_var_sp->m_flags |= ExpressionVariable::EVIsProgramReference;
return clang_var_sp->GetValueObject();
This patch does a few things: - 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
2014-12-10 03:51:20 +08:00
}
Add a way for source languages to "mark" ValueObjects with language-specific 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
2015-11-10 03:27:34 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
bool ValueObject::IsSyntheticChildrenGenerated() {
return m_is_synthetic_children_generated;
Add a way for source languages to "mark" ValueObjects with language-specific 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
2015-11-10 03:27:34 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
void ValueObject::SetSyntheticChildrenGenerated(bool b) {
m_is_synthetic_children_generated = b;
Add a way for source languages to "mark" ValueObjects with language-specific 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
2015-11-10 03:27:34 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** 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
2016-09-07 04:57:50 +08:00
uint64_t ValueObject::GetLanguageFlags() { return m_language_flags; }
void ValueObject::SetLanguageFlags(uint64_t flags) { m_language_flags = flags; }
Fix the variable view in the "gui" curses mode so that variables whose 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
2016-12-29 05:22:37 +08:00
ValueObjectManager::ValueObjectManager(lldb::ValueObjectSP in_valobj_sp,
lldb::DynamicValueType use_dynamic,
bool use_synthetic) : m_root_valobj_sp(),
m_user_valobj_sp(), m_use_dynamic(use_dynamic), m_stop_id(UINT32_MAX),
m_use_synthetic(use_synthetic) {
if (!in_valobj_sp)
return;
// If the user passes in a value object that is dynamic or synthetic, then
// water it down to the static type.
m_root_valobj_sp = in_valobj_sp->GetQualifiedRepresentationIfAvailable(lldb::eNoDynamicValues, false);
}
bool ValueObjectManager::IsValid() const {
if (!m_root_valobj_sp)
return false;
lldb::TargetSP target_sp = GetTargetSP();
if (target_sp)
return target_sp->IsValid();
return false;
}
lldb::ValueObjectSP ValueObjectManager::GetSP() {
lldb::ProcessSP process_sp = GetProcessSP();
if (!process_sp)
return lldb::ValueObjectSP();
const uint32_t current_stop_id = process_sp->GetLastNaturalStopID();
if (current_stop_id == m_stop_id)
return m_user_valobj_sp;
m_stop_id = current_stop_id;
if (!m_root_valobj_sp) {
m_user_valobj_sp.reset();
return m_root_valobj_sp;
}
m_user_valobj_sp = m_root_valobj_sp;
if (m_use_dynamic != lldb::eNoDynamicValues) {
lldb::ValueObjectSP dynamic_sp = m_user_valobj_sp->GetDynamicValue(m_use_dynamic);
if (dynamic_sp)
m_user_valobj_sp = dynamic_sp;
}
if (m_use_synthetic) {
lldb::ValueObjectSP synthetic_sp = m_user_valobj_sp->GetSyntheticValue(m_use_synthetic);
if (synthetic_sp)
m_user_valobj_sp = synthetic_sp;
}
return m_user_valobj_sp;
}
void ValueObjectManager::SetUseDynamic(lldb::DynamicValueType use_dynamic) {
if (use_dynamic != m_use_dynamic) {
m_use_dynamic = use_dynamic;
m_user_valobj_sp.reset();
m_stop_id = UINT32_MAX;
}
}
void ValueObjectManager::SetUseSynthetic(bool use_synthetic) {
if (m_use_synthetic != use_synthetic) {
m_use_synthetic = use_synthetic;
m_user_valobj_sp.reset();
m_stop_id = UINT32_MAX;
}
}
lldb::TargetSP ValueObjectManager::GetTargetSP() const {
if (!m_root_valobj_sp)
return m_root_valobj_sp->GetTargetSP();
return lldb::TargetSP();
}
lldb::ProcessSP ValueObjectManager::GetProcessSP() const {
if (m_root_valobj_sp)
return m_root_valobj_sp->GetProcessSP();
return lldb::ProcessSP();
}
lldb::ThreadSP ValueObjectManager::GetThreadSP() const {
if (m_root_valobj_sp)
return m_root_valobj_sp->GetThreadSP();
return lldb::ThreadSP();
}
lldb::StackFrameSP ValueObjectManager::GetFrameSP() const {
if (m_root_valobj_sp)
return m_root_valobj_sp->GetFrameSP();
return lldb::StackFrameSP();
}