| Commit message (Collapse) | Author | Age | Files | Lines |
|
|
|
|
|
|
|
|
|
|
| |
This is the conclusion of an effort to get LLDB's Python code
structured into a bona-fide Python package. This has a number
of benefits, but most notably the ability to more easily share
Python code between different but related pieces of LLDB's Python
infrastructure (for example, `scripts` can now share code with
`test`).
llvm-svn: 251532
|
|
|
|
| |
llvm-svn: 251444
|
|
|
|
|
|
|
|
|
|
|
| |
Python 3 has a different syntax for octal literals than Python 2
and they are incompatible with each other. Six doesn't provide
a transparent wrapper around this, so the most sane thing to do
is to not use octal literals. If you need an octal literal,
use a decimal literal and if it's not obvious what the value is,
provide the value in octal as a comment.
llvm-svn: 251328
|
|
|
|
|
|
|
| |
Plural methods were long deprecated, and in Python 3 they are gone.
Convert to the actual supported method names.
llvm-svn: 251303
|
|
|
|
| |
llvm-svn: 251129
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apparently there were tons of instances I missed last time, I
guess I accidentally ran 2to3 non-recursively. This should be
every occurrence of a print statement fixed to use a print function
as well as from __future__ import print_function being added to
every file.
After this patch print statements will stop working everywhere in
the test suite, and the print function should be used instead.
llvm-svn: 251121
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is necessary in order to allow third party modules to be
located under lldb/third_party rather than under the test
folder directly.
Since we're already touching every test file anyway, we also
go ahead and delete the unittest2 import and main block wherever
possible. The ability to run a test as a standalone file has
already been broken for some time, and if we decide we want this
back, we should use unittest instead of unittest2.
A few places could not have the import of unittest2 removed,because
they depend on the unittest2.expectedFailure or skip decorators.
Removing all those was orthogonal in spirit to the purpose of this
CL, so the import of unittest2 remains in those files that were
using it for its test decorators. Those can be addressed
separately.
llvm-svn: 251055
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"gcc" register numbers are now correctly referred to as "ehframe"
register numbers. In almost all cases, ehframe and dwarf register
numbers are identical (the one exception is i386 darwin where ehframe
regnums were incorrect).
The old "gdb" register numbers, which I incorrectly thought were
stabs register numbers, are now referred to as "Process Plugin"
register numbers. This is the register numbering scheme that the
remote process controller stub (lldb-server, gdbserver, core file
support, kdp server, remote jtag devices, etc) uses to refer to the
registers. The process plugin register numbers may not be contiguous
- there are remote jtag devices that have gaps in their register
numbering schemes.
I removed all of the enums for "gdb" register numbers that we had
in lldb - these were meaningless - and I put LLDB_INVALID_REGNUM
in all of the register tables for the Process Plugin regnum slot.
This change is almost entirely mechnical; the one actual change in
here is to ProcessGDBRemote.cpp's ParseRegisters() which parses the
qXfer:features:read:target.xml response. As it parses register
definitions from the xml, it will assign sequential numbers as the
eRegisterKindLLDB numbers (the lldb register numberings must be
sequential, without any gaps) and if the xml file specifies register
numbers, those will be used as the eRegisterKindProcessPlugin
register numbers (and those may have gaps). A J-Link jtag device's
target.xml does contain a gap in register numbers, and it only
specifies the register numbers for the registers after that gap.
The device supports many different ARM boards and probably selects
different part of its register file as appropriate.
http://reviews.llvm.org/D12791
<rdar://problem/22623262>
llvm-svn: 247741
|
|
|
|
|
|
|
|
|
|
|
|
| |
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:
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
|
|
|
|
| |
llvm-svn: 238411
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
-Fix darwin bot failure "unknown qSupported stub feature reported: qXfer:features:read"
-TestGdbRemoteAuxvSupport.py and TestLldbGdbServer.py were affected by this problem
Test Plan:
dotest.py -m --executable /Users/lldb_build/testSlave/buildDir/lldb.src/build/Debug/lldb --framework /Users/lldb_build/testSlave/buildDir/lldb.src/build/Debug/LLDB.framework -A x86_64 -C clang -p TestLldbGdbServer.py
dotest.py -m --executable /Users/lldb_build/testSlave/buildDir/lldb.src/build/Debug/lldb --framework /Users/lldb_build/testSlave/buildDir/lldb.src/build/Debug/LLDB.framework -A x86_64 -C clang -p TestGdbRemoteAuxvSupport.py
Reviewers: clayborg, sivachandra, vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D10043
llvm-svn: 238262
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
| |
Creates logs in session dir
Differential Revision: http://reviews.llvm.org/D9847
llvm-svn: 237931
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
| |
llvm-svn: 236958
|
|
|
|
| |
llvm-svn: 236803
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: When calling readlink, " (deleted)" is appended to executable path if it's deleted. Remove if it's there.
Reviewers: chaoren, sivachandra, vharron
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9583
llvm-svn: 236802
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Update to D9510.
Reviewers: chying, tberghammer, ovyalov
Reviewed By: ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9542
llvm-svn: 236688
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: chying, ovyalov
Reviewed By: chying, ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9510
llvm-svn: 236560
|
|
|
|
| |
llvm-svn: 236543
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: Add teardown hook to shutdown an inferior process
Reviewers: jasonmolenda, clayborg, tberghammer
Reviewed By: clayborg, tberghammer
Subscribers: lldb-commits, tberghammer, clayborg, jasonmolenda
Differential Revision: http://reviews.llvm.org/D9018
llvm-svn: 235005
|
|
|
|
|
|
| |
Differential revision: http://reviews.llvm.org/D8454
llvm-svn: 233531
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
|
As requested in http://reviews.llvm.org/D7545 this change moves test/tools/lldb-gdbserver to test/tools/lldb-server ot match the name of the target being tested.
Differential Revision: http://reviews.llvm.org/D8061
llvm-svn: 231479
|