Convert some functions to use StringRef instead of c_str, len

This started as an effort to change StringExtractor to store a
StringRef internally instead of a std::string. I got that working
locall

Convert some functions to use StringRef instead of c_str, len

This started as an effort to change StringExtractor to store a
StringRef internally instead of a std::string. I got that working
locally with just 1 test failure which I was unable to figure out the
cause of. But it was also a massive changelist due to a trickle
down effect of changes.

So I'm starting over, using what I learned from the first time to
tackle smaller, more isolated changes hopefully leading up to
a full conversion by the end.

At first the changes (such as in this CL) will seem mostly
a matter of preference and pointless otherwise. However, there
are some places in my larger CL where using StringRef turned 20+
lines of code into 2, drastically simplifying logic. Hopefully
once these go in they will illustrate some of the benefits of
thinking in terms of StringRef.

llvm-svn: 279917

show more ...

Introduce a MainLoop class and switch llgs to use it

Summary:
This is the first part of our effort to make llgs single threaded. Currently, llgs consists of
about three threads and the synchronisati

Introduce a MainLoop class and switch llgs to use it

Summary:
This is the first part of our effort to make llgs single threaded. Currently, llgs consists of
about three threads and the synchronisation between them is a major source of latency when
debugging linux and android applications.

In order to be able to go single threaded, we must have the ability to listen for events from
multiple sources (primarily, client commands coming over the network and debug events from the
inferior) and perform necessary actions. For this reason I introduce the concept of a MainLoop.
A main loop has the ability to register callback's which will be invoked upon receipt of certain
events. MainLoopPosix has the ability to listen for file descriptors and signals.

For the moment, I have merely made the GDBRemoteCommunicationServerLLGS class use MainLoop
instead of waiting on the network socket directly, but the other threads still remain. In the
followup patches I indend to migrate NativeProcessLinux to this class and remove the remaining
threads.

Reviewers: ovyalov, clayborg, amccarth, zturner, emaste

Subscribers: tberghammer, lldb-commits

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

llvm-svn: 242018

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 ...

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 ...

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 ...

Make lldb-platform to clear m_process_launch_info when hanlding qProcessInfo request - otherwise subsequent process launches will reuse data from previous launch.

llvm-svn: 228430

Add support for SBProcess::PutSTDIN to remote processes

Processes running on a remote target can already send $O messages
to send stdout but there is no way to send stdin to a remote
inferior.

This

Add support for SBProcess::PutSTDIN to remote processes

Processes running on a remote target can already send $O messages
to send stdout but there is no way to send stdin to a remote
inferior.

This allows processes using the API to pump stdin into a remote
inferior process.

It fixes a hang in TestProcessIO.py when running against a remote
target.

llvm-svn: 228419

show more ...

Extend SBPlatform with capability to launch/terminate a process remotely. Integrate this change into test framework in order to spawn processes on a remote target.

http://reviews.llvm.org/D7263

llv

Extend SBPlatform with capability to launch/terminate a process remotely. Integrate this change into test framework in order to spawn processes on a remote target.

http://reviews.llvm.org/D7263

llvm-svn: 228230

show more ...

Fix TestThreadStepOut on Linux with LLGS

Remove implicit stop action on $vCont package for threads where no
explicit action or default action specified based on the specification
(they have to stay

Fix TestThreadStepOut on Linux with LLGS

Remove implicit stop action on $vCont package for threads where no
explicit action or default action specified based on the specification
(they have to stay in there original state).

llvm-svn: 227933

show more ...

Add missing switch cases to silence warnings.

llvm-svn: 227931

Implement setting and clearing watchpoints.

llvm-svn: 227930

Moving header files from source/Host/common to proper location.

llvm-svn: 227929

Share crash information between LLGS and local POSIX debugging with
CrashReason class. Deliver crash information from LLGS to lldb via
description field of thread stop packet.

llvm-svn: 227926

Added support for writing registers larger than 64 bits

llvm-svn: 227919

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

Fixing TestRegisters on Linux with LLGS

This patch fixes TestRegisters on Linux with LLGS

Introduce GetUserRegisterCount on RegisterInfoInterface to distinguish
lldb internal registers (e.g.: DR0-D

Fixing TestRegisters on Linux with LLGS

This patch fixes TestRegisters on Linux with LLGS

Introduce GetUserRegisterCount on RegisterInfoInterface to distinguish
lldb internal registers (e.g.: DR0-DR7) during register counting.

Update GDBRemoteCommunicationServer to skip lldb internal registers on
read/write register and on discover register.

Submitted for Tamas Berghammer

llvm-svn: 226959

show more ...

This patch gets remote-linux platform able to run processes

Make sure the selected platform is always used

Make sure that the host uses the connect://hostname to connect to both
the lldb-platform a

This patch gets remote-linux platform able to run processes

Make sure the selected platform is always used

Make sure that the host uses the connect://hostname to connect to both
the lldb-platform and the lldb-gdbserver rather than what the platform
reports as the hostname of the lldb-gdbserver

Make sure that lldb-platform uses the IP address on it's connection
back to the host instead of the hostname that the host sends to it
when launching lldb-gdbserver with the remote host information

Tested on OSX and Linux

llvm-svn: 226712

show more ...

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 ...

Add D request handler to GDBRemoteCommunicationServer in order to support detach from inferior.

llvm-svn: 223901

Add Linux support for HostInfo::GetOSBuildString and HostInfo::GetOSKernelDescription.

llvm-svn: 223737

llgs: fixes to PTY/gdb-remote inferior stdout/stderr handling, logging addtions.

With this change, both local-process llgs and remote-target llgs stdout/stderr
handling from inferior work correctly.

llgs: fixes to PTY/gdb-remote inferior stdout/stderr handling, logging addtions.

With this change, both local-process llgs and remote-target llgs stdout/stderr
handling from inferior work correctly.

Several log lines have been added around PTY and stdout/stderr redirection
logic on the lldb client side.

Regarding remote llgs execution, see the following:

With these changes, remote llgs with $O now works properly:

$ lldb
(lldb) platform select remote-linux
(lldb) target create ~/some/inferior/exe
(lldb) gdb-remote {some-target}:{port}
(lldb) run

The sequence above will correctly redirect stdout/stderr over gdb-remote $O,
as is needed for remote debugging. That sequence assumes there is a lldb-gdbserver
exe running on the target with {some-host}:{port}.

You can replace the gdb-remote command with a '(lldb) platform connect
connect://{target-ip}:{target-port}'. If you do this and have a
lldb-platform running on the remote end, it will go ahead and launch
llgs for lldb for each target instance that is run/attached.

For local debugging with llgs, the following sequence also works, and
uses local PTYs instead to avoid $O and extra gdb-remote messages:

$ lldb
(lldb) settings set platform.plugin.linux.use-llgs true
(lldb) target create ~/some/inferior/exe
(lldb) run

The above will run the inferior using llgs on the local host, and
will use PTYs rather than $O redirection.

This change also removes the logging that happened after the fork but
before the exec when llgs is launching a new inferior process. Some
aspect of the file handling during that portion of code would not do
the right thing with log handling. We might want to go back later
and have that communicate over a pipe from the child to parent to pass
along any messages that previously were logged in that section of code.

llvm-svn: 219578

show more ...

Move ConnectionFileDescriptor to platform-specific Host directory.

As part of getting ConnectionFileDescriptor working on Windows,
there is going to be alot of platform specific work to be done.
As

Move ConnectionFileDescriptor to platform-specific Host directory.

As part of getting ConnectionFileDescriptor working on Windows,
there is going to be alot of platform specific work to be done.
As a result, the implementation is moving into Host. This patch
performs the code move and fixes up call-sites appropriately.

Reviewed by: Greg Clayton
Differential Revision: http://reviews.llvm.org/D5548

llvm-svn: 219143

show more ...

Test suite runs better again after recent fixes that would select a platform if a "file a.out" auto selected a different platform than the selected one.

Changes include:
- fix it so you can select t

Test suite runs better again after recent fixes that would select a platform if a "file a.out" auto selected a different platform than the selected one.

Changes include:
- fix it so you can select the "host" platform using "platform select host"
- change all callbacks that create platforms to returns shared pointers
- fix TestImageListMultiArchitecture.py to restore the "host" platform by running "platform select host"
- Add a new "PlatformSP Platform::Find(const ConstString &name)" method to get a cached platform
- cache platforms that are created and re-use them instead of always creating a new one

llvm-svn: 218145

show more ...

llgs: removed some wait-for-stop code in inferior process launch pipeline.

The $A handler was unnecessarily waiting for the launched app to hit a stop
before returning. Removed this code.

Renamed

llgs: removed some wait-for-stop code in inferior process launch pipeline.

The $A handler was unnecessarily waiting for the launched app to hit a stop
before returning. Removed this code.

Renamed the llgs inferior launching code to LaunchProcessForDebugging ()
to prevent it from possibly being mistaken as code that lldb-platform uses
to launch a debugserver process. We probably want to look at breaking out
llgs-specific and lldb-platform-specific code into separate derived classes,
with common code in a shared base class.

llvm-svn: 218075

show more ...

Hex encode the triple values in case they contain special characters.

llvm-svn: 218001