Summary: $PPID is not available on old shells.
Reviewers: tberghammer, ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10968
llvm-svn: 241486
Summary: Updated `append_to_remote_wd` to work for both remote and local.
Reviewers: clayborg, ovyalov
Reviewed By: ovyalov
Subscribers: tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D10288
llvm-svn: 239203
Summary:
This change also adds the infrastructure required to specify the API
levels for which tests should be skipped.
Reviewers: chying, labath
Reviewed By: labath
Subscribers: tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D10282
llvm-svn: 239183
Summary:
Not all of that register is readable/writable in user mode. This means
that even if the inferior is stopped, parts of the register could be
changing. So, do not flip this register to check if its value can be
restored.
Reviewers: tberghammer, chaoren
Reviewed By: tberghammer
Subscribers: rengolin, aemerson, lldb-commits
Differential Revision: http://reviews.llvm.org/D10204
llvm-svn: 239104
Summary:
This fixes TestLldbGdbServer and TestSendSignal from Windows to Android.
This change depends on D10171.
Reviewers: clayborg, ovyalov
Reviewed By: clayborg, ovyalov
Subscribers: tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D10172
llvm-svn: 238852
Summary:
Old Android devices, for example API 16, do not have the "readlink"
command. To take care of such devices, this commit changes to use "ls -l"
instead of "readlink" to get the lldb-server exe path.
The tests fixed with this change for an Android API 16 arm device are:
TestGdbRemoteAttach
TestGdbRemoteAuxvSupport
TestGdbRemoteExpeditedRegisters
TestGdbRemoteKill
TestGdbRemoteProcessInfo
TestGdbRemoteSegFault
TestGdbRemoteThreadsInStopReply
TestGdbRemote_qThreadStopInfo
Further, all tests in TestLldbGdbServer pass (previously erroring out),
except one which times out.
Test Plan:
Run dosep.py with 8 test threads targetting Android API 16
device.
Reviewers: vharron, ovyalov
Reviewed By: ovyalov
Subscribers: tberghammer, aemerson, lldb-commits
Differential Revision: http://reviews.llvm.org/D10107
llvm-svn: 238532
qEcho:%s
where '%s' is any valid string. The response to this packet is the exact packet itself with no changes, just reply with what you received!
This will help us to recover from packets timing out much more gracefully. Currently if a packet times out, LLDB quickly will hose up the debug session. For example, if we send a "abc" packet and we expect "ABC" back in response, but the "abc" command takes longer than the current timeout value this will happen:
--> "abc"
<-- <<<error: timeout>>>
Now we want to send "def" and get "DEF" back:
--> "def"
<-- "ABC"
We got the wrong response for the "def" packet because we didn't sync up with the server to clear any current responses from previously issues commands.
The fix is to modify GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock() so that when it gets a timeout, it syncs itself up with the client by sending a "qEcho:%u" where %u is an increasing integer, one for each time we timeout. We then wait for 3 timeout periods to sync back up. So the above "abc" session would look like:
--> "abc"
<-- <<<error: timeout>>> 1 second
--> "qEcho:1"
<-- <<<error: timeout>>> 1 second
<-- <<<error: timeout>>> 1 second
<-- "abc"
<-- "qEcho:1"
The first timeout is from trying to get the response, then we know we timed out and we send the "qEcho:1" packet and wait for 3 timeout periods to get back in sync knowing that we might actually get the response for the "abc" packet in the mean time...
In this case we would actually succeed in getting the response for "abc". But lets say the remote GDB server is deadlocked and will never response, it would look like:
--> "abc"
<-- <<<error: timeout>>> 1 second
--> "qEcho:1"
<-- <<<error: timeout>>> 1 second
<-- <<<error: timeout>>> 1 second
<-- <<<error: timeout>>> 1 second
We then disconnect and say we lost connection.
We might also have a bad GDB server that just dropped the "abc" packet on the floor. We can still recover in this case and it would look like:
--> "abc"
<-- <<<error: timeout>>> 1 second
--> "qEcho:1"
<-- "qEcho:1"
Then we know our remote GDB server is still alive and well, and it just dropped the "abc" response on the floor and we can continue to debug.
<rdar://problem/21082939>
llvm-svn: 238530
Summary:
The current sleep duration is not sufficient for Android.
[[ Its a completely different investigation as to why Android needs longer
sleep durations for this test. ]]
Test Plan: dotest.py -p TestLldbGdbServer on Android and local linux.
Reviewers: chaoren
Reviewed By: chaoren
Subscribers: tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D9926
llvm-svn: 237981
Depends on r237932
"Fixed intermittent failures in TestGdbRemote*/TestLldbGdbServer"
Test Plan:
Ran dosep 100x, no failures in these tests
Differential Revision: http://reviews.llvm.org/D9892
llvm-svn: 237933
test/tools/lldb-server/commandline/Test* were actually executing in
their parent directory. This looks fine at first because they aren't
compiling an inferior executable.
Unfortunately, they still call "make clean" during their cleanup,
which is likely causing all kinds of havok in tests running in the
parent directory
Differential Revision: http://reviews.llvm.org/D9869
llvm-svn: 237932
The lldb executable was referenced through the code by 7 different
(effectively) global variables.
global lldbExecutablePath
global lldbExecutable
os.environ['LLDB_EXEC']
os.environ['LLDB_TEST']
dotest.lldbExec
dotest.lldbHere
lldbtest.lldbExec
This change uses one global variable lldbtest_config.lldbExec to
replace them all.
Differential Revision: http://reviews.llvm.org/D9817
llvm-svn: 237600
Summary:
Since we don't yet have remote windows debugging, it should be safe to assume
that the remote target uses unix path separators.
Reviewers: ovyalov, zturner, clayborg, vharron
Reviewed By: vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9633
llvm-svn: 237006
Summary:
This patch fixes the following bug: https://llvm.org/bugs/show_bug.cgi?id=23181
For some reason some lldb-server tests should be kicked using SIGHUP and SIGINT before termination, otherwise it will leave a zombie process.
I think the reason is that the lldb-server will terminate a slave process if it gets the SIGHUP/SIGINT and if so it should be fixed in lldb-server.
The solution is to terminate process like it does the pexpect (including the delayafterterminate interval).
Also this patch reverts the following commits:
* r234549 - Skip lldb-server tests according to bug 23181
* r234765 - Skip a few tests on OS X according to the bug 23181
* r234803 - Skip the TestGdbRemoteRegisterState.test_grp_register_save_restore_works_no_suffix_debugserver_dsym test on OS X according to the bug 23181
Test Plan:
```
$ ps | grep Z | grep a.out | wc -l
447
$ ./dosep.py --options "-v --executable $INSTALLDIR/bin/lldb"
[...]
$ ps | grep Z | grep a.out | wc -l
447
```
Reviewers: jasonmolenda, clayborg, tberghammer
Reviewed By: clayborg
Subscribers: lldb-commits, dawn, tberghammer, clayborg, jasonmolenda
Differential Revision: http://reviews.llvm.org/D9019
llvm-svn: 235008
Adds @skipIfPlatform and @skipUnlessPlatform decorators which will skip if /
unless the target platform is in the provided platform list.
Test Plan:
ninja check-lldb shows no regressions.
When running cross platform, tests which cannot run on the target platform are
skipped.
Differential Revision: http://reviews.llvm.org/D8665
llvm-svn: 233547
On remote platform --setsid option is not used and currently it is also
impossible to get the sid of an lldb-platform instance running on a
remote target.
Differential revision: http://reviews.llvm.org/D8317
llvm-svn: 233081
To run tests against a different target platform many extra compiler flags are
needed to specify sysroot, include dirs, etc. The environment variable
CFLAGS_EXTRAS seems suited for this purpose except that several Makefiles
clobber the current flags. This change modifies all of these to add to
CFLAGS_EXTRAS instead.
Test Plan:
Verify no regressions in ninja check-lldb.
Run tests using CFLAGS_EXTRAS to specify cross compilation flags for a different
target running lldb-server platform.
Differential Revision: http://reviews.llvm.org/D8559
llvm-svn: 233066
Ninja apparently has issues with commands writing nul characters '\0' to stdout. When it
encounters a nul character, the rest of the output is skipped (I will file a bug with ninja about
that). This breaks the linux buildbot since it parses the ninja check-lldb output to get a list
of failures.
Recently, we have started outputting nul characters in lldb-server tests. This is probably
a bug in itself, but I am not addressing that now. This is just a workaround commit, which
prevents the nul characters from appearing in the output, and gets the buildbot operational again.
llvm-svn: 232805
The test cases in TestStubReverseConnect are using a socket connection
from python to lldb-server running on a remote target. To enable the
socket connection an adb port forwarding have to be set up when the
remote target is android.
Differential revision: http://reviews.llvm.org/D8319
llvm-svn: 232170
TestLldbGdbServer was failing because it always assumed AVX is available on
x86_64 Linux. This patch checks the target before asserting that AVX
registers are available.
llvm-svn: 232137
Summary:
This patch allows not specify search path in each lldb-mi test. It makes tests easier.
This fix was requested by vharron.
All test pass on OS X.
Reviewers: vharron, clayborg
Subscribers: lldb-commits, vharron
Differential Revision: http://reviews.llvm.org/D8207
llvm-svn: 232019
Previously these test cases execute lldb-server on the host and run the
tests against it even if a remote platform was specified. With this CL
these tests always test the communication with an lldb-server instance
running on the target.
Differential revision: http://reviews.llvm.org/D8202
llvm-svn: 231922
Tamas Berghammer