summaryrefslogtreecommitdiffstats
path: root/lldb/source/Interpreter/OptionValueSInt64.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Refactor OptionValue::SetValueFromCString to use llvm::StringRefPavel Labath2015-02-201-5/+5
| | | | | | | | | | Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D7676 llvm-svn: 230005
* Handle trailing spaces on "settings set" command more correctlyPavel Labath2015-02-161-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Currently we have some settings which treat "\ " on settings set commands specially. E.g., it is a valid way of specifying an argument of " " to a target. However, this fails if "\ " is the last argument as CommandObjectSettingsSet strips trailing whitespace. This resulted in a surprising argument of "\" to the target. This patch disables the training whitespace removal at a global level. Instead, for each argument type we locally determine whether whitespace stripping makes sense. Currently, I strip whitespace for all simple object type except of regex and format-string, with the rationale that these two object types do their own complex parsing and we want to interfere with them as least as possible. Specifically, stripping the whitespace of a regex "\ " will result in a (surprising?) error "trailing backslash". Furthermore, the default value of dissasembly-format setting already contains a trailing space and there is no way for the user to type this in manually if we strip whitespace. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D7592 llvm-svn: 229382
* Moved Args::StringToXIntYZ to StringConvert::ToXIntYZVince Harron2015-01-151-2/+2
| | | | | | | | | | 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
* Fixed an issue where if the operating system python plug-in is changed at ↵Greg Clayton2015-01-131-0/+2
| | | | | | | | | | | | | | | | | | | | | | | 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
* Resolve printf formatting warnings on Linux:Daniel Malea2012-11-291-3/+3
| | | | | | | | - use macros from inttypes.h for format strings instead of OS-specific types Patch from Matt Kopec! llvm-svn: 168945
* Reimplemented the code that backed the "settings" in lldb. There were many ↵Greg Clayton2012-08-221-0/+89
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
OpenPOWER on IntegriCloud