The Go interpreter doesn't JIT or use LLVM, so this also
moves all the JIT related code from UserExpression to a new class LLVMUserExpression.
Differential Revision: http://reviews.llvm.org/D13073
Fix merge
llvm-svn: 251820
packages/Python/lldbsuite is now a Python package, and it relies
on its __init__.py being called to do package-level initialization.
If you exec packages/Python/lldbsuite/dotest.py directly, you won't
get this package level initialization, and things will fail. But
without this patch, this is exactly what dosep itself does. To
launch the multi-processing fork, it was hardcoding a path to
dotest.py and exec'ing it from inside the package.
The fix here is to get the path of the top-level script, and
then exec'ing that instead. A more robust solution would involve
refactoring the code so that dosep execs some internal script that
imports lldbsuite, but that's a bit more involved.
Differential Revision: http://reviews.llvm.org/D14157
Reviewed by: Todd Fiala
llvm-svn: 251819
Summary:
As per the following link, the "--" separator can appear between the options
and parameters of any MI command. Previously this separator was only
handled by the `-data-disassemble` MI command. I have moved the relevant
code into `CMICmdBase` so that any MI command can handle the
aforementioned separator.
https://sourceware.org/gdb/onlinedocs/gdb/GDB_002fMI-Input-Syntax.html#GDB_002fMI-Input-Syntax
Reviewers: ki.stfu
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14197
llvm-svn: 251793
I don't think anything has changed recently - the test was always flaky, but
only very rarely. Still, it is causing noise in the buildbots.
llvm-svn: 251699
These are two simple tests that make sure single line and
multiline content are processed and received by Editline.cpp.
Fancier tests to come...
llvm-svn: 251681
It turns out that lldbtest_config was being imported locally to "lldbsuite.test" instead of globally, so when the test cases got individually brought by a global import via __import__ by unittest2, they did not see the lldbtest_config import, and ended up importing a new separate copy of it, with lldbExec unset
This is a simple hackaround that brings lldbtest_config to global visibility and makes sure the configuration data is correctly shared
llvm-svn: 251678
This is slightly harder to test because formatters cannot be added to language categories, so deletions are irreversible (in a debugger run)
I plan to add a test case soon, but I need to think about the right approach to obtain one
llvm-svn: 251660
Summary:
I observed that eclipse was passing --thread-group for many other commands
then we are currently handling. Looking at the MI documentation, the
following link states that each MI command accept the --thread and
--frame option. Looking at the GDB implementation, it seems that apart
from these 2, --thread-group is also handled the same way.
https://sourceware.org/gdb/onlinedocs/gdb/Context-management.html#Context-management
So instead of handling those arguments in every comamnds, I have moved
them into the base class and removed them from elsewhere. Now any command
can use these arguments. The patch seems big but most of the changes are
mechanical.
Reviewers: ki.stfu
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D14177
llvm-svn: 251636
The test was verifying that the pid of the child is not equal to its process
group by searching for text substrings. This failed in the rare cases when the
pid actually *was* a substring of the process group (even though they were not
equal).
Change the test to use SB API and do proper numeric comparisons.
llvm-svn: 251626
and decided to not commit the change, but accidentally committed
it anyway.
This was based on a static analysis complaint; it thought there
was a code path where AdbClient::PushFile would call AdbClient::ReadSyncHeader
and AdbClient::ReadSyncHeader wouldn't set data_len. But in that
case, the Error object returned will be Fail and we won't use
the data_len or response_id contents.
llvm-svn: 251580
StackFrame * (StackFrame is an ExecutionContextScope.) That allows you to call an
expression on a particular Thread, but not using the context of any particular frame.
That in turn is useful for injecting utility functions that don't actually depend on
locals/self/etc of the current frame.
I also had to include StackFrame.h in a couple of places so the compiler knew
how to downcast StackFrame to ExecutionContextScope.
<rdar://problem/22852953>
llvm-svn: 251564
Ryan Brown