The core of this change is the new CommandInterpreter::m_command_state, which
models the state transitions for interactive commands, including an
"interrupted" state transition.
In general, command interruption requires cooperation from the code executing
the command, which needs to poll for interruption requests through
CommandInterpreter::WasInterrupted().
CommandInterpreter::PrintCommandOutput() implements an optionally
interruptible printing of the command output, which for large outputs was
likely the longest blocking part. (ex. target modules dump symtab on a
complex binary could take 10+ minutes)
patch by lemo
Differential Revision: https://reviews.llvm.org/D37923
llvm-svn: 313904
The interpreter gets invoked in the sigint handler to cancel
long-running Python operations. That requires the interpreter
lock, but that may be held by the Python operation that's getting
interrupted, so the mutex needs to be recursive.
<rdar://problem/33179086>
llvm-svn: 307942
Summary:
The classes have no dependencies, and they are used both by lldb and
lldb-server, so it makes sense for them to live in the lowest layers.
Reviewers: zturner, jingham
Subscribers: emaste, mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D34746
llvm-svn: 306682
The Timer destructor would grab a global mutex in order to update
execution time. Add a class to define a category once, statically; the
class adds itself to an atomic singly linked list, and thus subsequent
updates only need to use an atomic rather than grab a lock and perform a
hashtable lookup.
Differential Revision: https://reviews.llvm.org/D32823
Patch by Scott Smith <scott.smith@purestorage.com>.
llvm-svn: 303058
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
This updates the regular expression used to match host/port pairs for the gdb-remote command to also match IPv6 addresses.
The IPv6 address matcher is very generic and does not really check for structural validity of the address. It turns out that IPv6 addresses are very complicated.
llvm-svn: 301559
The attribute was fairly dubious as: a) we shouldn't tell the compiler
when to inline functions, b) GCC complains that the function may be
not always inlinable.
llvm-svn: 300377
All references to Host and Core have been removed, so this
class can now safely be lowered into Utility.
Differential Revision: https://reviews.llvm.org/D30559
llvm-svn: 296909
This moves the following classes from Core -> Utility.
ConstString
Error
RegularExpression
Stream
StreamString
The goal here is to get lldbUtility into a state where it has
no dependendencies except on itself and LLVM, so it can be the
starting point at which to start untangling LLDB's dependencies.
These are all low level and very widely used classes, and
previously lldbUtility had dependencies up to lldbCore in order
to use these classes. So moving then down to lldbUtility makes
sense from both the short term and long term perspective in
solving this problem.
Differential Revision: https://reviews.llvm.org/D29427
llvm-svn: 293941
LLDB needs some minor changes to adopt PrettyStackTrace after https://reviews.llvm.org/D27683.
We remove our own SetCrashDescription() function and use LLVM-provided RAII objects instead.
We also make sure LLDB doesn't define __crashtracer_info__ which would collide with LLVM's definition.
Differential Revision: https://reviews.llvm.org/D27735
llvm-svn: 289711
I found the race condition in:
ScriptInterpreter *CommandInterpreter::GetScriptInterpreter(bool can_create);
More than one "ScriptInterpreter *" was being returned due to the race which caused any clients with the first one to now be pointing to freed memory and we would quickly crash.
Added a test to catch this so we don't regress.
<rdar://problem/28356584>
llvm-svn: 289169
The long-term goal here is to get rid of the functions
GetArgumentAtIndex() and GetQuoteCharAtIndex(), instead
replacing them with operator based access and range-based for
enumeration. There are a lot of callsites, though, so the
changes will be done incrementally, starting with this one.
Differential Revision: https://reviews.llvm.org/D26883
llvm-svn: 287597
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
This makes the logic easier to follow and also propagates
StringRef up to the API boundary, which is necessary for
making higher up StringRef API changes.
Differential Revision: https://reviews.llvm.org/D26325
llvm-svn: 286204
This is better for a number of reasons. Mostly style, but also:
1) Signed-unsigned comparison warnings disappear since there is
no loop index.
2) Iterating with the range-for style gives you back an entry
that has more than just a const char*, so it's more efficient
and more useful.
3) Makes code safter since the type system enforces that it's
impossible to index out of bounds.
llvm-svn: 283413
This converts Args::Unshift, Args::AddOrReplaceEnvironmentVariable,
and Args::ContainsEnvironmentVariable to use StringRefs. The code
is also simplified somewhat as a result.
llvm-svn: 281942
This patch also marks the const char* versions as =delete to prevent
their use. This has the potential to cause build breakages on some
platforms which I can't compile. I have tested on Windows, Linux,
and OSX. Best practices for fixing broken callsites are outlined in
Args.h in a comment above the deleted function declarations.
Eventually we can remove these =delete declarations, but for now they
are important to make sure that all implicit conversions from
const char * are manually audited to make sure that they do not invoke a
conversion from nullptr.
llvm-svn: 281919
*** to conform to clang-format’s LLVM style. This kind of mass change has
*** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} +
find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
It's always hard to remember when to include this file, and
when you do include it it's hard to remember what preprocessor
check it needs to be behind, and then you further have to remember
whether it's windows.h or win32.h which you need to include.
This patch changes the name to PosixApi.h, which is more appropriately
named, and makes it independent of any preprocessor setting.
There's still the issue of people not knowing when to include this,
because there's not a well-defined set of things it exposes other
than "whatever is missing on Windows", but at least this should
make it less painful to fix when problems arise.
This patch depends on LLVM revision r278170.
llvm-svn: 278177
review it for consistency, accuracy, and clarity. These changes attempt to
address all of the above while keeping the text relatively terse.
<rdar://problem/24868841>
llvm-svn: 275485
This option evaluates an expression and, if the result is of pointer type, treats it as if it was an array of that many elements and displays such elements
This has a couple subtle points but is mostly as straightforward as it sounds
Add a parray N <expr> alias for this new mode
Also, extend the --object-description mode to do the moral equivalent of the above but display each element in --object-description mode
Add a poarray N <expr> alias for this
llvm-svn: 267372
This solves issues such as 'apropos foo' returning valid matches just because syntax examples happen to use 'foo' as a placeholder token
Fixes rdar://9043025
llvm-svn: 264123
It would be nice to have a longer-term plan for how to handle help for regular expression commands, since their syntax is highly irregular. I can see a few options (*), but for now this is a reasonable stop-gag measure for the most blatant regression.
(*) the simplest is, of course, to detect a regex command and inherit the syntax for any aliases thereof; it would be nice if this also didn't show the underlying regex command name when the alias is used
llvm-svn: 263523
This cleans things up such CommandAlias essentially can work as its own object; the aliases still live in a separate map, but are now just full-fledged CommandObjectSPs
This patch also cleans up help generation for aliases, allows aliases to vend their own help, and adds a tweak such that "dash-dash aliases", such as po, don't show the list of options for their underlying command, since those can't be provided anyway
I plan to fix up a few more things here, and then add a test case and proclaim victory
llvm-svn: 263499
