llgs Linux is no longer doing the translation to some gdb fixed signal
numbers. This change modifies the test method to take in the signo
expected for a segfault. The debugserver test uses the fixed gdb number,
and everything else uses signal.SIGSEGV for the platform.
Sidenote: I somehow did not see this reported in multicore tests.
I will need to verify that we aren't missing test failures in that
script. I need to verify why this wasn't more obvious with
test/dosep.py.
llvm-svn: 216770
And likewise for qProcessInfo on Linux, but ensures cputype/cpusubtype is not defined. The
Apple case is the more important one, since we take a slightly different path to initialize
ProcessGDBRemote-related remote host/process info if triple is present.
Related to http://llvm.org/bugs/show_bug.cgi?id=20755.
llvm-svn: 216473
This change addresses this bug:
http://llvm.org/bugs/show_bug.cgi?id=20755
This change:
* Modifies llgs to send triple instead of cputype and cpusubtype when not on Apple platforms in qProcessInfo.
* Modifies lldb's GDBRemoteCommunicationClient to handle the triple returned from qProcessInfo if given.
When given, it will prefer to use triple over cputype and cpusubtype.
* Adds gdb-remote protocol tests to verify that cputype and cpusubtype are specified on darwin, and that triple is specified on Linux.
llvm-svn: 216470
I'm about to add some more qProcessInfo tests so I wanted to first pull them out
of the monolithic TestLldbGdbServer test case class.
Related to http://llvm.org/bugs/show_bug.cgi?id=20755
llvm-svn: 216465
Many of the test executables use pthreads directly. This isn't
portable on Windows, so this patch converts these test to use
C++11 threads and mutexes. Since Windows' implementation of
std::thread classes throw and catch from header files, this patch
also disables exceptions when compiling with clang on Windows.
Reviewed by: Todd Fiala, Ed Maste
Differential Revision: http://reviews.llvm.org/D4816
llvm-svn: 215562
Added llgs/debugserver gdb-remote tests around SIGABRT and SIGSEGV signal reception
notification. Found a few bugs in exception signal handling in Linux llgs. Fixed those.
llvm-svn: 215458
The test produces lines that start with "<word>: " which confuses the
buildbot log parser. Disable the test until either the test is fixed
or the buildbot can deal with the undesired output.
llvm.org/pr20545
llvm-svn: 214900
Previously, CMake was invoking the test runner and not specifying
what architecture to use when building test executables. The
Makefiles for the test executables then had logic to choose x64
by default. This doesn't work on Windows because the test compiler
would then try to link against the 64-bit MSVCRT and not find them
since only the 32-bit MSVCRT was in the path.
This patch addresses this by figuring out, at CMake time, whether
or not you are building LLDB with a 64 or 32-bit toolchain. Then,
it explicitly passes this value to the test runner, causing the
test runner to build tests whose architecture matches that of LLDB
itself. This can still be overridden by setting the CMake variable
LLDB_TEST_EXECUTABLE_ARCH=(x64|x86)
llvm-svn: 214443
This was causing core dumps on MacOSX and was not properly
cleaning up the state of the inferior before exiting.
The test was overriding def tearDown(), but failed to
call the base class after doing its own cleanup. This
essentially eliminated normal clean-up activity.
llvm-svn: 214138
Currently, the test runner makes the assumption that it will run
commands through /bin/sh. This is obviously not true on Windows,
so this patch abstracts this logic out somewhat. Instead of
having the caller build the command string himself, the caller
will now pass in argument list of the form [[a, b], [c, d], ...]
which will get converted into a string of the form a b; c d or
a b && c d, depending on the platform.
Reviewed by: Todd Fiala
Differential Revision: http://reviews.llvm.org/D4590
llvm-svn: 213669
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
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
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
Kuba Brecka