lldb -P, which outputs its python path, works by using Host-layer
facilities to get information about the loaded python module.  This
Host functionality was unimplemented on Windows, so this patch
implements it.  Additionally, it removes a pexpect dependency from
the test runner and uses an equivalent invocation of subprocess.

Reviewed by: Todd Fiala

Differential Revision: http://reviews.llvm.org/D4548

llvm-svn: 213410

99% of this CL is simply moving calls to "import pexpect" to a more
narrow scope - i.e. the function that actually runs a particular
test.  This way the test suite can run on Windows, which doesn't have
pexpect, and the individual tests that use pexpect can be disabled on
a platform-specific basis.

Additionally, this CL fixes a few other cases of non-portability.
Notably, using "ps" to get the command line, and os.uname() to
determine the architecture don't work on Windows.  Finally, this
also adds a stubbed out builder_win32 module.

The full test suite runs correctly on Windows after this CL, although
there is still some work remaining on the C++ side to fix one-shot
script commands from LLDB (e.g. script print "foo"), which currently
deadlock.

Reviewed by: Todd Fiala

Differential Revision: http://reviews.llvm.org/D4573

llvm-svn: 213343

This fixes all of the hidden ivar test cases and any case where we try to find the full definition of an objective C class.

This also means hidden ivars show up again.

<rdar://problem/15458957>
llvm.org/pr20270
llvm.org/pr20269
llvm.org/pr20272

llvm-svn: 213328

This change adds a member to the base test case for gdb-remote that
indicates whether a stub makes two X stop notification reports on kill
commands.  This is set to true for debugserver tests.

The test for killing an attached process after it's first stop notification
has been modified to look at that flag and add an extra X packet matcher
so the "unmatched packet warning" doesn't get emitted for the second X on
MacOSX with debugserver.

I also broke those tests out of the monolithic TestLldbGdbServer mega test
case and put it in its own, new TestGdbRemoteKill.py file and test case.

Tested:
Ubuntu 14.04 x86_64, clang-3.5 built lldb, no test failures.
MacOSX 10.9.4, Xcode 6.0 Beta 3 built lldb, no test failures.

llvm-svn: 213166

Fixed the test case to use a runtime function prototype that will be correct ([NSString stringWithCString: "new"]) instead of one that won't (expression str = [NSString stringWithFormat: @"%cew", 'N']). The runtime doesn't track vararg functions correctly so we can't reconstitute the function correctly.

Also fixed some expressions that used "str_id" whose type was "id" and do the necessary casting since "id" doesn't have any methods.

llvm-svn: 213113

<rdar://problem/16322133>
llvm.org/pr20267

llvm-svn: 213111

llvm-svn: 213106

Now that llgs supports communicating the 0-port choose-a-port
mechanism and can communicate that back to a caller via the
--named-pipe option (at parity with debugserver), we use this
mechanism to always start llgs and debugserver gdb-remote
protocol tests without needing to use some port arbitration
mechanism.  This eliminates some potential intermittent failures vs. the
previous random port and collision-avoidance strategy used.

llvm-svn: 212923

The testrun now completes successfully on my FreeBSD 11.0-CURRENT
laptop.  There are some intermittent failures on the FreeBSD buildbot
still, which should be addressed in later commits.

llvm.org/pr20274

llvm-svn: 212878

llvm.org/pr20282

llvm-svn: 212877

The --setsid (-S) option changes the session id for the lldb-gdbserver process.
This is used by tools such as lldb-platform and allows the user to prevent
llgs from being in the same session as a calling terminal session.
This will prevents terminal group control signals from affecting
lldb-gdbserver.

See also:
https://github.com/tfiala/lldb/issues/38

llvm-svn: 212873

Added a unit test to test debugserver and llgs compliance on --named-pipe support.

Modified llgs to implement --named-pipe support.  (Note: need to revisit with
new generic pipe support).

llvm-svn: 212854

The following intermittently-failing tests have been flipped from
skip to XFAIL on some combo of Linux and MacOSX:

TestCallStopAndContinue.py (Linux, MacOSX)
TestCallWithTimeout.py (Linux)
TestConvenienceVariables.py (Linux)
TestStopHookMultipleThreads.py (Linux)

The following new tests have been marked XFAIL but are just
intermittently failing:

TestMultipleDebug.py (definitely intermittent on MacOSX, not sure I've seen
it pass yet on Linux)

llvm-svn: 212762

of hardcoding it.

llvm-svn: 212698

llvm-svn: 212694

llvm-svn: 212673

debug sessions simultaneously to expose race conditoin/locking
issues.

This directory has an inferior program, testprog.cpp that has a
couple of functions we can put breakpoints on.

It has a driver program, multi-process-driver.cpp, which links
against the LLDB solib and uses the SB APIs.  It creates 50 pthreads,
creates a debugger on all of them, launches a debug session of the
inferior testprog, hits a couple breakpoints, walks the stack,
continues, etc., and then kills the inferior and ends the debug
session.

A pass is if all fifty debug sessions complete successfully
in the alloted time (~60 seconds).

We may need to tweak this one to work correctly on different
platforms/targets but I wanted to get it checked in to start.

llvm-svn: 212671

Marked skipped for Linux:
TestCallStopAndContinue
TestConvenienceVariables
TestStopHookMultipleThreads

Fixed up gdb-remote port-grabbing code to use a random port in a wide range,
and to allow that to fail more gracefully.  This appears to have solved some
gdb-remote intermittent failing behavior.

llvm-svn: 212662

These are failing intermittently.

See http://llvm.org/bugs/show_bug.cgi?id=19246 for TestCallThatRestarts.  Also applies to Linux.
See http://llvm.org/bugs/show_bug.cgi?id=20274 for TestCallStopAndContinue.

llvm-svn: 212660

See http://llvm.org/bugs/show_bug.cgi?id=20273

llvm-svn: 212659

http://llvm.org/bugs/show_bug.cgi?id=20272

llvm-svn: 212657

See http://llvm.org/bugs/show_bug.cgi?id=20271

llvm-svn: 212656

See http://llvm.org/bugs/show_bug.cgi?id=20270

llvm-svn: 212655

See http://llvm.org/bugs/show_bug.cgi?id=20269

llvm-svn: 212654

Marked TestObjCMethods failing tests XFAIL, fixed cleanup code, removed now-passing expected failure markers.

All tests matching '-p TestObjCMethods' now are marked correctly for MacOSX, and some
error classes have been removed in cleanup code looking for files that
might not exist due to previous failure.

See http://llvm.org/bugs/show_bug.cgi?id=20267

llvm-svn: 212650

See http://llvm.org/bugs/show_bug.cgi?id=20266

llvm-svn: 212648

See http://llvm.org/bugs/show_bug.cgi?id=20265

llvm-svn: 212647

See http://llvm.org/bugs/show_bug.cgi?id=20264

llvm-svn: 212646

See http://llvm.org/bugs/show_bug.cgi?id=20263

llvm-svn: 212645

See http://llvm.org/bugs/show_bug.cgi?id=20260 for more details.

llvm-svn: 212639

Change by Paul Osmialowski

See http://reviews.llvm.org/D4379 for details.

llvm-svn: 212583

llvm-svn: 212553

Remove hack from dotest.py to fix extra output on -P command, and fix MacOSX multi-threaded test run collisions on crashlog.dylib.

On MacOSX, we need to adjust the way we clean up the crashlog dylib in deleteCrashInfoDylib().
Right now it is only geared to run one test at a time.  For now I'm just skipping the delete.
I'll work with Apple on a fix that handles this.  It seems to only cause one dylib total to
hang around that might otherwise have been deleted.  Fixes MacOSX multiple tests running
at the same time.  (I didn't hit this on Yosemite, might be an issue that only shows up
on Mavericks?)

llvm-svn: 212548

This change modifies the way the multi-threaded test runner works.
It uses the Python multiprocessing library rather than the threading
library.  Investigation showed that all MacOSX threads were waiting on
the global python lock when using the threading approach.  Not sure
why that differed from the Linux/FreeBSD implementations.

The new approach uses the multiprocessing library's Pool class.  It's
mildly cleaner than the other version, runs multithreaded on MacOSX,
and seems to have caused no performance regression on Linux.  The
worker thread logic is simpler with the Pool managing the worker
processes.

This also includes a minor change to the test runner's python
lldb dir logic using the -P option.  It now looks at the last line
of output rather than the first line.  This covers part of the issue
of extra options validation logic getting spit out.  The test runner
will now pick up the right python library directory.  It does not
fix all the issues, though, as a ton of tests (50+ on Linux) are
failing due to unexpected output when running lldb.

llvm-svn: 212513

when you continue to finish off the function call, the expression result
will be included as part of the thread stop info.

llvm-svn: 212506

See http://llvm.org/bugs/show_bug.cgi?id=20233 for details.

llvm-svn: 212491

See http://llvm.org/bugs/show_bug.cgi?id=20232 for details.

llvm-svn: 212489

See http://llvm.org/bugs/show_bug.cgi?id=20231

llvm-svn: 212488

See http://www.llvm.org/bugs/show_bug.cgi?id=20230 for details.

llvm-svn: 212486

breakpoint should return false from IsValid.

llvm-svn: 212206