| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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)
Differential Revision: https://reviews.llvm.org/D37923
llvm-svn: 315037
|
|
|
|
|
|
|
|
|
|
|
|
| |
particular causes lldb to die on startup if you have a ~/.lldbinit file.
I filed:
https://bugs.llvm.org/show_bug.cgi?id=34758
to cover fixing the bug.
llvm-svn: 314371
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Patch by Jessica Han <jessicah@juniper.net>
https://reviews.llvm.org/D35525
llvm-svn: 309238
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 297640
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 289746
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
crashing LLDB.
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
|
|
|
|
| |
llvm-svn: 288797
|
|
|
|
|
|
| |
This fixes the build breakage due to the use of C++14.
llvm-svn: 287647
|
|
|
|
|
|
| |
Linux and BSD builds failing after this changes from rev 287597.
llvm-svn: 287631
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 287401
|
|
|
|
| |
llvm-svn: 287157
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 286906
|
|
|
|
| |
llvm-svn: 286743
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: zturner, labath
Subscribers: tberghammer, danalbert, lldb-commits
Differential Revision: https://reviews.llvm.org/D26233
llvm-svn: 285855
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 283386
|
|
|
|
| |
llvm-svn: 283385
|
|
|
|
| |
llvm-svn: 283384
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D25247
llvm-svn: 283344
|
|
|
|
|
|
| |
I missed an if/else branch when doing the conversion.
llvm-svn: 283176
|
|
|
|
|
|
|
| |
Mostly this involves simplifying some logical constructs and using
some ranges instead of index-based iteration. NFC
llvm-svn: 283159
|
|
|
|
| |
llvm-svn: 282269
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
as an existing alias (or rather, one could but the results of invoking the command were far from satisfactory)
llvm-svn: 275080
|
|
|
|
|
|
|
|
| |
command names for nested command objects
rdar://problem/26020072
llvm-svn: 268309
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
| |
spawning an inferior process
llvm-svn: 266911
|
|
|
|
| |
llvm-svn: 265819
|
|
|
|
|
|
|
|
|
|
| |
strings for commands
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
|
|
|
|
|
|
| |
its parent command by setting itself to an empty help string
llvm-svn: 264108
|
|
|
|
|
|
| |
terms of another alias, trying to run the nested command would actually cause a crash in the command interpreter
llvm-svn: 264096
|
|
|
|
| |
llvm-svn: 263865
|
|
|
|
|
|
|
|
|
|
| |
"_regexp-break", and thus "help b" doesn't show the possible syntaxes
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
|