Modify "platform connect" to connect to processes as well

The standard remote debugging workflow with gdb is to start the
application on the remote host under gdbserver (e.g.: gdbserver :5039
a.out)

Modify "platform connect" to connect to processes as well

The standard remote debugging workflow with gdb is to start the
application on the remote host under gdbserver (e.g.: gdbserver :5039
a.out) and then connect to it with gdb.

The same workflow is supported by debugserver/lldb-gdbserver with a very
similar syntax but to access all features of lldb we need to be
connected also to an lldb-platform instance running on the target.

Before this change this had to be done manually with starting a separate
lldb-platform on the target machine and then connecting to it with lldb
before connecting to the process.

This change modifies the behavior of "platform connect" with
automatically connecting to the process instance if it was started by
the remote platform. With this command replacing gdbserver in a gdb
based worflow is usually as simple as replacing the command to execute
gdbserver with executing lldb-platform.

Differential revision: http://reviews.llvm.org/D14952

llvm-svn: 255016

show more ...

Add domain socket support to gdb-remote protocol and lldb-server.

http://reviews.llvm.org/D13881

llvm-svn: 250933

Allow LLDB.framework to locate debugserver even when it doesn't exist in the LLDB.framework.

This allows open source MacOSX clients to not have to build debugserver and the current LLDB can find deb

Allow LLDB.framework to locate debugserver even when it doesn't exist in the LLDB.framework.

This allows open source MacOSX clients to not have to build debugserver and the current LLDB can find debugserver inside the selected Xcode.app on your system.

<rdar://problem/23167253>

llvm-svn: 250735

show more ...

A small fixup needed for debugserver to work natively
on iOS devices; fallout from Vince's cleanups made
in r237218 back in May. iOS native lldbs will call
StartDebugserverProcess() with a random po

A small fixup needed for debugserver to work natively
on iOS devices; fallout from Vince's cleanups made
in r237218 back in May. iOS native lldbs will call
StartDebugserverProcess() with a random port #
(see ProcessGDBRemote::LaunchAndConnectToDebugserver)
and neither side of this conditional expression should
be followed in that case.

I added an "if (in_port == 0) { ..." check around the
entire if/then/else and indented the block of code so
the diff looks larger than it really is.

<rdar://problem/21712643>

llvm-svn: 248343

show more ...

A change I'm open to reverting if there is disagreement:
When lldb receives a gdb-remote protocol packet that has
nonprintable characters, it will print the packet in
gdb-remote logging with binary-h

A change I'm open to reverting if there is disagreement:
When lldb receives a gdb-remote protocol packet that has
nonprintable characters, it will print the packet in
gdb-remote logging with binary-hex encoding so we don't
dump random 8-bit characters into the packet log.

I'm changing this check to allow whitespace characters
(newlines, linefeeds, tabs) to be printed if those are
the only non-printable characters in the packet.

This is primarily to get the response to the
qXfer:features:read:target.xml packet to show up in the
packet logs in human readable form. Right now we just
get a dozen kilobytes of hex-ascii and it's hard to
figure out what register number scheme is being used.

llvm-svn: 247120

show more ...

GDBRemoteCommunication::DecompressPacket assumed that the buffer it was
working with (the Communication m_bytes ivar) contained a single packet.
Instead, it may contain multitudes. Find the boundari

GDBRemoteCommunication::DecompressPacket assumed that the buffer it was
working with (the Communication m_bytes ivar) contained a single packet.
Instead, it may contain multitudes. Find the boundaries of the first packet
in the buffer and replace that with the decompressed version leaving the
rest of the buffer unmodified.
<rdar://problem/21841377>

llvm-svn: 243846

show more ...

Use only unnamed pipes to launch lldb-server gdbserver.

Summary:
If we used unnamed pipes instead of named pipes, we can avoid having the
file system littered with debugserver-named-pipes if lldb-se

Use only unnamed pipes to launch lldb-server gdbserver.

Summary:
If we used unnamed pipes instead of named pipes, we can avoid having the
file system littered with debugserver-named-pipes if lldb-server happens to
crash for whatever reason. Also, on some buggy systems, it's possible to be
able to create but not to delete a fifo. Ideally, support for unnamed pipes
should be added to debugserver as well, so we can avoid the `#ifdef` here.

Reviewers: clayborg, vharron, chying

Subscribers: lldb-commits

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

llvm-svn: 243667

show more ...

Add comment explaning sanity check on packet size in the packet decompression method.

llvm-svn: 242184

Fix off-by-one error in the packet decompression routine
that would not pass through empty ("unsupported packet") replies
correctly.

llvm-svn: 242119

Add a new wart, I mean feature, on to gdb-remote protocol: compression.
For some communication channels, sending large packets can be very
slow. In those cases, it may be faster to compress the con

Add a new wart, I mean feature, on to gdb-remote protocol: compression.
For some communication channels, sending large packets can be very
slow. In those cases, it may be faster to compress the contents of
the packet on the target device and decompress it on the debug host
system. For instance, communicating with a device using something
like Bluetooth may be an environment where this tradeoff is a good one.

This patch adds a new field to the response to the "qSupported" packet
(which returns a "qXfer:features:" response) -- SupportedCompressions
and DefaultCompressionMinSize. These tell you what the remote
stub can support.

lldb, if it wants to enable compression and can handle one of those
algorithms, it can send a QEnableCompression packet specifying the
algorithm and optionally the minimum packet size to use compression
on. lldb may have better knowledge about the best tradeoff for
a given communication channel.

I added support to debugserver an lldb to use the zlib APIs
(if -DHAVE_LIBZ=1 is in CFLAGS and -lz is in LDFLAGS) and the
libcompression APIs on Mac OS X 10.11 and later
(if -DHAVE_LIBCOMPRESSION=1). libz "zlib-deflate" compression.
libcompression can support deflate, lz4, lzma, and a proprietary
lzfse algorithm. libcompression has been hand-tuned for Apple
hardware so it should be preferred if available.

debugserver currently only adds the SupportedCompressions when
it is being run on an Apple watch (TARGET_OS_WATCH). Comment
that #if out from RNBRemote.cpp if you want to enable it to
see how it works. I haven't tested this on a native system
configuration but surely it will be slower to compress & decompress
the packets in a same-system debug session.

I haven't had a chance to add support for this to
GDBRemoteCommunciationServer.cpp yet.

<rdar://problem/21090180>

llvm-svn: 240066

show more ...

Add Read Thread to GDBRemoteCommunication

In order to support asynchronous notifications for non-stop mode this patch adds a packet read thread. This is done by implementing AppendBytesToCache() fro

Add Read Thread to GDBRemoteCommunication

In order to support asynchronous notifications for non-stop mode this patch adds a packet read thread. This is done by implementing AppendBytesToCache() from the communications class, which continually reads packets into a packet queue. To initialize this thread StartReadThread() must be called by the client, so since llgs and platform tools use the GBDRemoteCommunicatos code they must also call this function as well as ProcessGDBRemote.

When the read thread detects an async notify packet it broadcasts this event, where the matching listener will be added in the next non-stop patch.

Packets are now accessed by calling ReadPacket() which pops a packet from the queue, instead of using WaitForPacketWithTimeoutMicroSecondsNoLock()

Reviewers: vharron, clayborg

Subscribers: lldb-commits, labath, ted, domipheus, deepak2427

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

llvm-svn: 239824

show more ...

Add a new "qEcho" packet with the following format:

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 receive

Add a new "qEcho" packet with the following format:

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

show more ...

Change ProcessGDBRemote last stop packet to a container.

In ProcessGDBRemote we currently have a single packet, m_last_stop_packet, used to set the thread stop info.
However in non-stop mode we can

Change ProcessGDBRemote last stop packet to a container.

In ProcessGDBRemote we currently have a single packet, m_last_stop_packet, used to set the thread stop info.
However in non-stop mode we can receive several stop reply packets in a sequence for different threads. As a result we need to use a container to hold them before they are processed.

This patch also changes the return type of CheckPacket() so we can detect async notification packets.

Reviewers: clayborg

Subscribers: labath, ted, deepak2427, lldb-commits

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

llvm-svn: 238323

show more ...

Remote Non-Stop Support

Summary:

This patch is the beginnings of support for Non-stop mode in the remote protocol. Letting a user examine stopped threads, while other threads execute freely.

Non

Remote Non-Stop Support

Summary:

This patch is the beginnings of support for Non-stop mode in the remote protocol. Letting a user examine stopped threads, while other threads execute freely.

Non-stop mode is enabled using the setting target.non-stop-mode, which sends a QNonStop packet when establishing the remote connection.
Changes are also made to treat the '?' stop reply packet differently in non-stop mode, according to spec https://sourceware.org/gdb/current/onlinedocs/gdb/Remote-Non_002dStop.html#Remote-Non_002dStop.
A setting for querying the remote for default thread on setup is also included.

Handling of '%' async notification packets will be added next.

Reviewers: clayborg

Subscribers: lldb-commits, ADodds, ted, deepak2427

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

llvm-svn: 237239

show more ...

Fixed a ton of gcc compile warnings

Removed some unused variables, added some consts, changed some casts
to const_cast. I don't think any of these changes are very
controversial.

Differential Revis

Fixed a ton of gcc compile warnings

Removed some unused variables, added some consts, changed some casts
to const_cast. I don't think any of these changes are very
controversial.

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

llvm-svn: 237218

show more ...

Get lldb-server building on android-9

Build lldb-server with an android-9 sysroot.

llvm-svn: 237078

Add support for ./dotest.py --channel and --log-success

Summary:
New dotest options that allow arbitrary log channels and
categories to be enabled. Also enables logging for locally run
debug server

Add support for ./dotest.py --channel and --log-success

Summary:
New dotest options that allow arbitrary log channels and
categories to be enabled. Also enables logging for locally run
debug servers.

Log messages are separated into separate files per test case.
(this makes it possible to log in dosep runs)

These new log files are stored side-by-side with trace files in the
session directory.

These files are deleted by default if the test run is successful.

If --log-success is specified, even successful logs are retained.

--log-success is useful for creating reference log files.

Test Plan:
add '--channel "lldb all" --channel "gdb-remote packets" --log-success'
to your dotest options

Tested on OSX and Linux

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

llvm-svn: 236956

show more ...

Add an unnamed pipe fail-safe to launching lldb-gdbserver.

Summary:
Currently, launching lldb-gdbserver from platform on Android requires root for
mkfifo() and an explicit TMPDIR variable. This shou

Add an unnamed pipe fail-safe to launching lldb-gdbserver.

Summary:
Currently, launching lldb-gdbserver from platform on Android requires root for
mkfifo() and an explicit TMPDIR variable. This should remove both requirements.

Test Plan: Successfully launched lldb-gdbserver on a non-rooted Android device.

Reviewers: tberghammer, vharron, clayborg

Reviewed By: clayborg

Subscribers: tberghammer, lldb-commits

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

llvm-svn: 235940

show more ...

Move several plugin to its own namespace

Affected paths:
* Plugins/Platform/Android/*
* Plugins/Platform/Linux/*
* Plugins/Platform/gdb-server/*
* Plugins/Process/Linux/*
* Plugins/Process/gdb-remot

Move several plugin to its own namespace

Affected paths:
* Plugins/Platform/Android/*
* Plugins/Platform/Linux/*
* Plugins/Platform/gdb-server/*
* Plugins/Process/Linux/*
* Plugins/Process/gdb-remote/*

Differential revision: http://reviews.llvm.org/D8654

llvm-svn: 233679

show more ...

Create ScopedTimeout class for GDBRemoteCommunication

This new class makes it easier to change the timeout of a
GDBRemoteCommunication instance for a short time and then restore it to
its original v

Create ScopedTimeout class for GDBRemoteCommunication

This new class makes it easier to change the timeout of a
GDBRemoteCommunication instance for a short time and then restore it to
its original value.

Differential revision: http://reviews.llvm.org/D7826

llvm-svn: 230319

show more ...

Merge lldb-platform and lldb-gdbserver into a single binary

This commit merges lldb-platform and lldb-gdbserver into a single binary
of the same size as each of the previous individual binaries. Exe

Merge lldb-platform and lldb-gdbserver into a single binary

This commit merges lldb-platform and lldb-gdbserver into a single binary
of the same size as each of the previous individual binaries. Execution
mode is controlled by the first argument being either platform or
gdbserver.

Patch from: flackr <flackr@google.com>

Differential revision: http://reviews.llvm.org/D7545

llvm-svn: 229683

show more ...

Separate monolithic GDBRemoteCommunicationServer class into 4 part

GDBRemoteCommunicationServer: Basic packet handling, handler registration
LLDBCommonPacketHandler: Common packet handling for lldb-

Separate monolithic GDBRemoteCommunicationServer class into 4 part

GDBRemoteCommunicationServer: Basic packet handling, handler registration
LLDBCommonPacketHandler: Common packet handling for lldb-platform and lldb-gdbserver
LLDBPlatformPacketHandler: lldb-platform specific packet handling
LLGSPacketHandler: lldb-gdbserver specific packet handling

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

llvm-svn: 228823

show more ...

Fix warning about the use of mktemp and make platform agnostic by adding and using PipeBase::CreateWithUniqueName - on behalf of flackr.

http://reviews.llvm.org/D7348

llvm-svn: 228307

Launch lldb-gdbserver in same process group when launched remotely using lldb-platform - commit on behalf of flackr.

http://reviews.llvm.org/D7211

llvm-svn: 227329

Moved Args::StringToXIntYZ to StringConvert::ToXIntYZ

The refactor was motivated by some comments that Greg made
http://reviews.llvm.org/D6918

and also to break a dependency cascade that caused fun

Moved Args::StringToXIntYZ to StringConvert::ToXIntYZ

The refactor was motivated by some comments that Greg made
http://reviews.llvm.org/D6918

and also to break a dependency cascade that caused functions linking
in string->int conversion functions to pull in most of lldb

llvm-svn: 226199

show more ...