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

311 lines
12 KiB
C++
Raw Normal View History

Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
//===-- Property.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/Interpreter/Property.h"
// C Includes
// C++ Includes
// Other libraries and framework includes
// Project includes
#include "lldb/Core/UserSettingsController.h"
Moved Args::StringToXIntYZ to StringConvert::ToXIntYZ The refactor was motivated by some comments that Greg made http://reviews.llvm.org/D6918 and also to break a dependency cascade that caused functions linking in string->int conversion functions to pull in most of lldb llvm-svn: 226199
2015-01-16 04:08:35 +08:00
#include "lldb/Host/StringConvert.h"
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
#include "lldb/Interpreter/CommandInterpreter.h"
#include "lldb/Interpreter/OptionValues.h"
Move things from the LanguageRuntime that obviously belong in the new Language plugin instead. llvm-svn: 246611
2015-09-02 09:06:46 +08:00
#include "lldb/Target/Language.h"
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
using namespace lldb;
using namespace lldb_private;
Property::Property (const PropertyDefinition &definition) :
m_name (definition.name),
m_description (definition.description),
m_value_sp (),
m_is_global (definition.global)
{
switch (definition.type)
{
case OptionValue::eTypeInvalid:
case OptionValue::eTypeProperties:
break;
case OptionValue::eTypeArch:
// "definition.default_uint_value" is not used
// "definition.default_cstr_value" as a string value that represents the default string value for the architecture/triple
m_value_sp.reset (new OptionValueArch(definition.default_cstr_value));
break;
case OptionValue::eTypeArgs:
// "definition.default_uint_value" is always a OptionValue::Type
m_value_sp.reset (new OptionValueArgs());
break;
case OptionValue::eTypeArray:
// "definition.default_uint_value" is always a OptionValue::Type
m_value_sp.reset (new OptionValueArray(OptionValue::ConvertTypeToMask((OptionValue::Type)definition.default_uint_value)));
break;
case OptionValue::eTypeBoolean:
// "definition.default_uint_value" is the default boolean value if
// "definition.default_cstr_value" is NULL, otherwise interpret
// "definition.default_cstr_value" as a string value that represents the default
// value.
if (definition.default_cstr_value)
Switch NULL to C++11 nullptr in source/Interpreter Patch by Robert Matusewicz llvm-svn: 206711
2014-04-20 08:31:37 +08:00
m_value_sp.reset (new OptionValueBoolean(Args::StringToBoolean (definition.default_cstr_value, false, nullptr)));
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
else
m_value_sp.reset (new OptionValueBoolean(definition.default_uint_value != 0));
break;
Add support for character option types. This will allow, in a subsequent patch, the addition of a global setting that allows the user to specify a single character that LLDB will recognize as an escape character when processing arg strings to accomodate differences in Windows/non-Windows path handling. Differential Revision: http://reviews.llvm.org/D6887 Reviewed by: Jim Ingham llvm-svn: 225694
2015-01-13 04:44:02 +08:00
case OptionValue::eTypeChar:
m_value_sp.reset(new OptionValueChar(Args::StringToChar(definition.default_cstr_value, '\0', nullptr)));
break;
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
case OptionValue::eTypeDictionary:
// "definition.default_uint_value" is always a OptionValue::Type
m_value_sp.reset (new OptionValueDictionary(OptionValue::ConvertTypeToMask((OptionValue::Type)definition.default_uint_value)));
break;
case OptionValue::eTypeEnum:
// "definition.default_uint_value" is the default enumeration value if
// "definition.default_cstr_value" is NULL, otherwise interpret
// "definition.default_cstr_value" as a string value that represents the default
// value.
{
OptionValueEnumeration *enum_value = new OptionValueEnumeration(definition.enum_values, definition.default_uint_value);
m_value_sp.reset (enum_value);
if (definition.default_cstr_value)
{
Refactor OptionValue::SetValueFromCString to use llvm::StringRef Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D7676 llvm-svn: 230005
2015-02-20 19:14:59 +08:00
if (enum_value->SetValueFromString(definition.default_cstr_value).Success())
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
{
enum_value->SetDefaultValue(enum_value->GetCurrentValue());
// Call Clear() since we don't want the value to appear as
Refactor OptionValue::SetValueFromCString to use llvm::StringRef Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D7676 llvm-svn: 230005
2015-02-20 19:14:59 +08:00
// having been set since we called SetValueFromString() above.
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
// Clear will set the current value to the default and clear
// the boolean that says that the value has been set.
enum_value->Clear();
}
}
}
break;
case OptionValue::eTypeFileSpec:
Fix SettingsCommandTestCase.test_set_error_output_path target.error-path (and output-path) were getting resolved on the local file system, which doesn't make any sense for remote targets So this patch prevents file paths from being resolved on the host system. llvm-svn: 229763
2015-02-19 07:12:26 +08:00
{
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
// "definition.default_uint_value" represents if the "definition.default_cstr_value" should
// be resolved or not
Fix SettingsCommandTestCase.test_set_error_output_path target.error-path (and output-path) were getting resolved on the local file system, which doesn't make any sense for remote targets So this patch prevents file paths from being resolved on the host system. llvm-svn: 229763
2015-02-19 07:12:26 +08:00
const bool resolve = definition.default_uint_value != 0;
m_value_sp.reset (new OptionValueFileSpec(FileSpec(definition.default_cstr_value, resolve), resolve));
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
break;
Fix SettingsCommandTestCase.test_set_error_output_path target.error-path (and output-path) were getting resolved on the local file system, which doesn't make any sense for remote targets So this patch prevents file paths from being resolved on the host system. llvm-svn: 229763
2015-02-19 07:12:26 +08:00
}
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
case OptionValue::eTypeFileSpecList:
// "definition.default_uint_value" is not used for a OptionValue::eTypeFileSpecList
m_value_sp.reset (new OptionValueFileSpecList());
break;
case OptionValue::eTypeFormat:
// "definition.default_uint_value" is the default format enumeration value if
// "definition.default_cstr_value" is NULL, otherwise interpret
// "definition.default_cstr_value" as a string value that represents the default
// value.
Get rid of Debugger::FormatPrompt() and replace it with the new FormatEntity class. Why? Debugger::FormatPrompt() would run through the format prompt every time and parse it and emit it piece by piece. It also did formatting differently depending on which key/value pair it was parsing. The new code improves on this with the following features: 1 - Allow format strings to be parsed into a FormatEntity::Entry which can contain multiple child FormatEntity::Entry objects. This FormatEntity::Entry is a parsed version of what was previously always done in Debugger::FormatPrompt() so it is more efficient to emit formatted strings using the new parsed FormatEntity::Entry. 2 - Allows errors in format strings to be shown immediately when setting the settings (frame-format, thread-format, disassembly-format 3 - Allows auto completion by implementing a new OptionValueFormatEntity and switching frame-format, thread-format, and disassembly-format settings over to using it. 4 - The FormatEntity::Entry for each of the frame-format, thread-format, disassembly-format settings only replaces the old one if the format parses correctly 5 - Combines all consecutive string values together for efficient output. This means all "${ansi.*}" keys and all desensitized characters like "\n" "\t" "\0721" "\x23" will get combined with their previous strings 6 - ${*.script:} (like "${var.script:mymodule.my_var_function}") have all been switched over to use ${script.*:} "${script.var:mymodule.my_var_function}") to make the format easier to parse as I don't believe anyone was using these format string power user features. 7 - All key values pairs are defined in simple C arrays of entries so it is much easier to add new entries. These changes pave the way for subsequent modifications where we can modify formats to do more (like control the width of value strings can do more and add more functionality more easily like string formatting to control the width, printf formats and more). llvm-svn: 228207
2015-02-05 06:00:53 +08:00
{
Format new_format = eFormatInvalid;
if (definition.default_cstr_value)
Args::StringToFormat (definition.default_cstr_value, new_format, nullptr);
else
new_format = (Format)definition.default_uint_value;
m_value_sp.reset (new OptionValueFormat(new_format));
}
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
break;
Add an OptionValueLanguage class llvm-svn: 230046
2015-02-21 03:46:30 +08:00
case OptionValue::eTypeLanguage:
// "definition.default_uint_value" is the default language enumeration value if
// "definition.default_cstr_value" is NULL, otherwise interpret
// "definition.default_cstr_value" as a string value that represents the default
// value.
{
LanguageType new_lang = eLanguageTypeUnknown;
if (definition.default_cstr_value)
Move things from the LanguageRuntime that obviously belong in the new Language plugin instead. llvm-svn: 246611
2015-09-02 09:06:46 +08:00
Language::GetLanguageTypeFromString(definition.default_cstr_value);
Add an OptionValueLanguage class llvm-svn: 230046
2015-02-21 03:46:30 +08:00
else
new_lang = (LanguageType)definition.default_uint_value;
m_value_sp.reset (new OptionValueLanguage(new_lang));
}
break;
Get rid of Debugger::FormatPrompt() and replace it with the new FormatEntity class. Why? Debugger::FormatPrompt() would run through the format prompt every time and parse it and emit it piece by piece. It also did formatting differently depending on which key/value pair it was parsing. The new code improves on this with the following features: 1 - Allow format strings to be parsed into a FormatEntity::Entry which can contain multiple child FormatEntity::Entry objects. This FormatEntity::Entry is a parsed version of what was previously always done in Debugger::FormatPrompt() so it is more efficient to emit formatted strings using the new parsed FormatEntity::Entry. 2 - Allows errors in format strings to be shown immediately when setting the settings (frame-format, thread-format, disassembly-format 3 - Allows auto completion by implementing a new OptionValueFormatEntity and switching frame-format, thread-format, and disassembly-format settings over to using it. 4 - The FormatEntity::Entry for each of the frame-format, thread-format, disassembly-format settings only replaces the old one if the format parses correctly 5 - Combines all consecutive string values together for efficient output. This means all "${ansi.*}" keys and all desensitized characters like "\n" "\t" "\0721" "\x23" will get combined with their previous strings 6 - ${*.script:} (like "${var.script:mymodule.my_var_function}") have all been switched over to use ${script.*:} "${script.var:mymodule.my_var_function}") to make the format easier to parse as I don't believe anyone was using these format string power user features. 7 - All key values pairs are defined in simple C arrays of entries so it is much easier to add new entries. These changes pave the way for subsequent modifications where we can modify formats to do more (like control the width of value strings can do more and add more functionality more easily like string formatting to control the width, printf formats and more). llvm-svn: 228207
2015-02-05 06:00:53 +08:00
case OptionValue::eTypeFormatEntity:
// "definition.default_cstr_value" as a string value that represents the default
m_value_sp.reset (new OptionValueFormatEntity(definition.default_cstr_value));
break;
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
case OptionValue::eTypePathMap:
// "definition.default_uint_value" tells us if notifications should occur for
// path mappings
m_value_sp.reset (new OptionValuePathMappings(definition.default_uint_value != 0));
break;
case OptionValue::eTypeRegex:
// "definition.default_uint_value" is used to the regular expression flags
// "definition.default_cstr_value" the default regular expression value
// value.
Abstract the details from regex.h a bit more by not allowing people to specify compile and execute flags for regular expressions. Also enable better regular expressions if they are available by check if the REG_ENHANCED is available and using it if it is. Since REG_ENHANCED is available on MacOSX, this allow the use of \d (digits) \b (word boundaries) and much more without affecting other systems. <rdar://problem/12082562> llvm-svn: 226704
2015-01-22 05:51:02 +08:00
m_value_sp.reset (new OptionValueRegex(definition.default_cstr_value));
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
break;
case OptionValue::eTypeSInt64:
// "definition.default_uint_value" is the default integer value if
// "definition.default_cstr_value" is NULL, otherwise interpret
// "definition.default_cstr_value" as a string value that represents the default
// value.
Moved Args::StringToXIntYZ to StringConvert::ToXIntYZ The refactor was motivated by some comments that Greg made http://reviews.llvm.org/D6918 and also to break a dependency cascade that caused functions linking in string->int conversion functions to pull in most of lldb llvm-svn: 226199
2015-01-16 04:08:35 +08:00
m_value_sp.reset (new OptionValueSInt64(definition.default_cstr_value ? StringConvert::ToSInt64 (definition.default_cstr_value) : definition.default_uint_value));
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
break;
case OptionValue::eTypeUInt64:
// "definition.default_uint_value" is the default unsigned integer value if
// "definition.default_cstr_value" is NULL, otherwise interpret
// "definition.default_cstr_value" as a string value that represents the default
// value.
Moved Args::StringToXIntYZ to StringConvert::ToXIntYZ The refactor was motivated by some comments that Greg made http://reviews.llvm.org/D6918 and also to break a dependency cascade that caused functions linking in string->int conversion functions to pull in most of lldb llvm-svn: 226199
2015-01-16 04:08:35 +08:00
m_value_sp.reset (new OptionValueUInt64(definition.default_cstr_value ? StringConvert::ToUInt64 (definition.default_cstr_value) : definition.default_uint_value));
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
break;
case OptionValue::eTypeUUID:
// "definition.default_uint_value" is not used for a OptionValue::eTypeUUID
// "definition.default_cstr_value" can contain a default UUID value
Get rid of Debugger::FormatPrompt() and replace it with the new FormatEntity class. Why? Debugger::FormatPrompt() would run through the format prompt every time and parse it and emit it piece by piece. It also did formatting differently depending on which key/value pair it was parsing. The new code improves on this with the following features: 1 - Allow format strings to be parsed into a FormatEntity::Entry which can contain multiple child FormatEntity::Entry objects. This FormatEntity::Entry is a parsed version of what was previously always done in Debugger::FormatPrompt() so it is more efficient to emit formatted strings using the new parsed FormatEntity::Entry. 2 - Allows errors in format strings to be shown immediately when setting the settings (frame-format, thread-format, disassembly-format 3 - Allows auto completion by implementing a new OptionValueFormatEntity and switching frame-format, thread-format, and disassembly-format settings over to using it. 4 - The FormatEntity::Entry for each of the frame-format, thread-format, disassembly-format settings only replaces the old one if the format parses correctly 5 - Combines all consecutive string values together for efficient output. This means all "${ansi.*}" keys and all desensitized characters like "\n" "\t" "\0721" "\x23" will get combined with their previous strings 6 - ${*.script:} (like "${var.script:mymodule.my_var_function}") have all been switched over to use ${script.*:} "${script.var:mymodule.my_var_function}") to make the format easier to parse as I don't believe anyone was using these format string power user features. 7 - All key values pairs are defined in simple C arrays of entries so it is much easier to add new entries. These changes pave the way for subsequent modifications where we can modify formats to do more (like control the width of value strings can do more and add more functionality more easily like string formatting to control the width, printf formats and more). llvm-svn: 228207
2015-02-05 06:00:53 +08:00
{
UUID uuid;
if (definition.default_cstr_value)
uuid.SetFromCString (definition.default_cstr_value);
m_value_sp.reset (new OptionValueUUID(uuid));
}
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
break;
case OptionValue::eTypeString:
Made it so changes to the prompt via "settings set prompt" get noticed by the command line. Added the ability for OptionValueString objects to take flags. The only flag is currently for parsing escape sequences. Not the prompt string can have escape characters translate which will allow colors in the prompt. Added functions to Args that will parse the escape sequences in a string, and also re-encode the escape sequences for display. This was looted from other parts of LLDB (the Debugger::FormatString() function). llvm-svn: 163043
2012-09-01 08:38:36 +08:00
// "definition.default_uint_value" can contain the string option flags OR'ed together
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
// "definition.default_cstr_value" can contain a default string value
Made it so changes to the prompt via "settings set prompt" get noticed by the command line. Added the ability for OptionValueString objects to take flags. The only flag is currently for parsing escape sequences. Not the prompt string can have escape characters translate which will allow colors in the prompt. Added functions to Args that will parse the escape sequences in a string, and also re-encode the escape sequences for display. This was looted from other parts of LLDB (the Debugger::FormatString() function). llvm-svn: 163043
2012-09-01 08:38:36 +08:00
{
OptionValueString *string_value = new OptionValueString(definition.default_cstr_value);
if (definition.default_uint_value != 0)
string_value->GetOptions().Reset(definition.default_uint_value);
m_value_sp.reset (string_value);
}
Reimplemented the code that backed the "settings" in lldb. There were many issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
2012-08-23 01:17:09 +08:00
break;
}
}
Property::Property (const ConstString &name,
const ConstString &desc,
bool is_global,
const lldb::OptionValueSP &value_sp) :
m_name (name),
m_description (desc),
m_value_sp (value_sp),
m_is_global (is_global)
{
}
bool
Property::DumpQualifiedName(Stream &strm) const
{
if (m_name)
{
if (m_value_sp->DumpQualifiedName(strm))
strm.PutChar('.');
strm << m_name;
return true;
}
return false;
}
void
Property::Dump (const ExecutionContext *exe_ctx, Stream &strm, uint32_t dump_mask) const
{
if (m_value_sp)
{
const bool dump_desc = dump_mask & OptionValue::eDumpOptionDescription;
const bool transparent = m_value_sp->ValueIsTransparent ();
if (dump_desc || !transparent)
{
if ((dump_mask & OptionValue::eDumpOptionName) && m_name)
{
DumpQualifiedName(strm);
if (dump_mask & ~OptionValue::eDumpOptionName)
strm.PutChar(' ');
}
}
if (dump_desc)
{
const char *desc = GetDescription();
if (desc)
strm.Printf ("-- %s", desc);
if (transparent && (dump_mask == (OptionValue::eDumpOptionName | OptionValue::eDumpOptionDescription)))
strm.EOL();
}
m_value_sp->DumpValue(exe_ctx, strm, dump_mask);
}
}
void
Property::DumpDescription (CommandInterpreter &interpreter,
Stream &strm,
uint32_t output_width,
bool display_qualified_name) const
{
if (m_value_sp)
{
const char *desc = GetDescription();
if (desc)
{
StreamString qualified_name;
const OptionValueProperties *sub_properties = m_value_sp->GetAsProperties();
if (sub_properties)
{
strm.EOL();
if (m_value_sp->DumpQualifiedName(qualified_name))
strm.Printf("'%s' variables:\n\n", qualified_name.GetString().c_str());
sub_properties->DumpAllDescriptions(interpreter, strm);
}
else
{
if (desc)
{
if (display_qualified_name)
{
StreamString qualified_name;
DumpQualifiedName(qualified_name);
interpreter.OutputFormattedHelpText (strm,
qualified_name.GetString().c_str(),
"--",
desc,
output_width);
}
else
{
interpreter.OutputFormattedHelpText (strm,
m_name.GetCString(),
"--",
desc,
output_width);
}
}
}
}
}
}
Fixed an issue where if the operating system python plug-in is changed at runtime, it wouldn't cause the process to reload the new operating system plug-in, now it does. This is currently controlled by a setting: (lldb) settings set target.process.python-os-plugin-path <path> Or clearing it with: (lldb) settings clear target.process.python-os-plugin-path The process will now reload the OperatingSystem plug-in. This was implemented by: - adding the ability to set a notify callback for when an option value is changed - added the ability for the process plug-in to load the operating system plug-in on the fly - fixed bugs in the Process::GetStatus() so all threads are displayed if their thread IDs are larger than 32 bits - adding a callback in ProcessProperties to tell when the "python-os-plugin-path" is changed by the user - fixing a crasher in ProcessMachCore that happens when updating the thread list when the OS plugin is reloaded llvm-svn: 225831
2015-01-14 05:13:08 +08:00
void
Property::SetValueChangedCallback (OptionValueChangedCallback callback, void *baton)
{
if (m_value_sp)
m_value_sp->SetValueChangedCallback (callback, baton);
}