Unify process launching code on linux

Summary:
We've had two copies of code for launching processes:
- one in NativeProcessLinux, used for launching debugged processes
- one in ProcessLauncherAndroi

Unify process launching code on linux

Summary:
We've had two copies of code for launching processes:
- one in NativeProcessLinux, used for launching debugged processes
- one in ProcessLauncherAndroid, used on android for launching all other kinds of processes

These have over time acquired support for various launch options, but neither supported all of
them. I now replace them with a single implementation ProcessLauncherLinux, which supports all
the options the individual versions supported and set it to be used to launch all processes on
linux.

This also works around the ETXTBSY issue on android when the process is started from the platform
instance, as that used to go through the version which did not contain the workaround.

Reviewers: tberghammer

Subscribers: tberghammer, danalbert, srhines, lldb-commits

Differential Revision: https://reviews.llvm.org/D22457

llvm-svn: 276288

show more ...

Remove platform plugins from lldb-server

Summary:
This removes the last usage of Platform plugins in lldb-server -- it was used for launching child
processes, where it can be trivially replaced by H

Remove platform plugins from lldb-server

Summary:
This removes the last usage of Platform plugins in lldb-server -- it was used for launching child
processes, where it can be trivially replaced by Host::LaunchProces (as lldb-server is always
running on the host).

Removing platform plugins enables us to remove a lot of other unused code, which was pulled in as
a transitive dependency, and it reduces lldb-server size by 4%--9% (depending on build type and
architecture).

Reviewers: clayborg

Subscribers: tberghammer, danalbert, srhines, lldb-commits

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

llvm-svn: 274125

show more ...

remove use of Mutex in favour of std::{,recursive_}mutex

This is a pretty straightforward first pass over removing a number of uses of
Mutex in favor of std::mutex or std::recursive_mutex. The probl

remove use of Mutex in favour of std::{,recursive_}mutex

This is a pretty straightforward first pass over removing a number of uses of
Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there
are interfaces which take Mutex::Locker & to lock internal locks. This patch
cleans up most of the easy cases. The only non-trivial change is in
CommandObjectTarget.cpp where a Mutex::Locker was split into two.

llvm-svn: 269877

show more ...

Add -Wimplicit-fallthrough command line option to clang in
the xcode project file to catch switch statements that have a
case that falls through unintentionally.

Define LLVM_FALLTHROUGH to indicate

Add -Wimplicit-fallthrough command line option to clang in
the xcode project file to catch switch statements that have a
case that falls through unintentionally.

Define LLVM_FALLTHROUGH to indicate instances where a case has code
and intends to fall through. This should be in llvm/Support/Compiler.h;
Peter Collingbourne originally checked in there (r237766), then
reverted (r237941) because he didn't have time to mark up all the
'case' statements that were intended to fall through. I put together
a patch to get this back in llvm http://reviews.llvm.org/D17063 but
it hasn't been approved in the past week. I added a new
lldb-private-defines.h to hold the definition for now.

Every place in lldb where there is a comment that the fall-through
is intentional, I added LLVM_FALLTHROUGH to silence the warning.
I haven't tried to identify whether the fallthrough is a bug or
not in the other places.

I haven't tried to add this to the cmake option build flags.
This warning will only work for clang.

This build cleanly (with some new warnings) on macosx with clang
under xcodebuild, but if this causes problems for people on other
configurations, I'll back it out.

llvm-svn: 260930

show more ...

Improve the functionality of JSONNumber

* Add support for representing signed integers
* Add new constructors taking any signed or unsigned integer types

Differential revision: http://reviews.llvm.

Improve the functionality of JSONNumber

* Add support for representing signed integers
* Add new constructors taking any signed or unsigned integer types

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

llvm-svn: 254715

show more ...

[LLGS] Don't forward I/O when process is stopped

Summary:
This makes sure we do not attempt to send output over the gdb-remote protocol when the client is
not expecting it (i.e., after sending the s

[LLGS] Don't forward I/O when process is stopped

Summary:
This makes sure we do not attempt to send output over the gdb-remote protocol when the client is
not expecting it (i.e., after sending the stop-reply packet). Normally, this should not happen
(the process cannot generate output when it is stopped), but due to the fact that pty
communication is asynchronous in the linux kernel (llvm.org/pr25652), we may sometimes get this
output too late. Instead, we just hold the output, and send it next time we resume. This is not
ideal, but at least it makes sure we do not violate the remote protocol. Given that this happens
extremely rarely it's not worth trying to work around it with sleeps or something like that.

I also remove the m_stdio_communication_mutex, as all of LLGS is now single-threaded anyway.

Reviewers: tberghammer, ovyalov

Subscribers: lldb-commits

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

llvm-svn: 254200

show more ...

[lldb-server] Send PC of every thread along in the stop-reply packet

This avoids the need to query the PC for private resume operations (public resumes have the PC
from the bigger jStopInfo packet)

[lldb-server] Send PC of every thread along in the stop-reply packet

This avoids the need to query the PC for private resume operations (public resumes have the PC
from the bigger jStopInfo packet) and speeds up the stepping on an android target by about 10%
(it some cases even more).

llvm-svn: 251301

show more ...

lldb-server: add support for binary memory reads

Summary:
This commit adds support for binary memory reads ($x) to lldb-server. It also removes the "0x"
prefix from the $x client packet, to make it

lldb-server: add support for binary memory reads

Summary:
This commit adds support for binary memory reads ($x) to lldb-server. It also removes the "0x"
prefix from the $x client packet, to make it more compatible with the old $m packet. This allows
us to use almost the same code for handling both packet types. I have verified that debugserver
correctly handles $x packets even without the leading "0x". I have added a test which verifies
that the stub returns the same memory contents for both kinds of memory reads ($x and $m).

Reviewers: tberghammer, jasonmolenda

Subscribers: iancottrell, lldb-commits

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

llvm-svn: 250295

show more ...

Clean up register naming conventions inside lldb.

"gcc" register numbers are now correctly referred to as "ehframe"
register numbers. In almost all cases, ehframe and dwarf register
numbers are i

Clean up register naming conventions inside lldb.

"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

show more ...

A messy bit of cleanup: Move towards more descriptive names
for eh_frame and stabs register numberings. This is not
complete but it's a step in the right direction. It's almost
entirely mechanical.

A messy bit of cleanup: Move towards more descriptive names
for eh_frame and stabs register numberings. This is not
complete but it's a step in the right direction. It's almost
entirely mechanical.

lldb informally uses "gcc register numbering" to mean eh_frame.
Why? Probably because there's a notorious bug with gcc on i386
darwin where the register numbers in eh_frame were incorrect.
In all other cases, eh_frame register numbering is identical to
dwarf.

lldb informally uses "gdb register numbering" to mean stabs.
There are no official definitions of stabs register numbers
for different architectures, so the implementations of gdb
and gcc are the de facto reference source.

There were some incorrect uses of these register number types
in lldb already. I fixed the ones that I saw as I made
this change.

This commit changes all references to "gcc" and "gdb" register
numbers in lldb to "eh_frame" and "stabs" to make it clear
what is actually being represented.

lldb cannot parse the stabs debug format, and given that no
one is using stabs any more, it is unlikely that it ever will.
A more comprehensive cleanup would remove the stabs register
numbers altogether - it's unnecessary cruft / complication to
all of our register structures.

In ProcessGDBRemote, when we get register definitions from
the gdb-remote stub, we expect to see "gcc:" (qRegisterInfo)
or "gcc_regnum" (qXfer:features:read: packet to get xml payload).
This patch changes ProcessGDBRemote to also accept "ehframe:"
and "ehframe_regnum" from these remotes.

I did not change GDBRemoteCommunicationServerLLGS or debugserver
to send these new packets. I don't know what kind of interoperability
constraints we might be working under. At some point in the future
we should transition to using the more descriptive names.

Throughout lldb we're still using enum names like "gcc_r0" and "gdb_r0",
for eh_frame and stabs register numberings. These should be cleaned
up eventually too.

The sources link cleanly on macosx native with xcode build. I
don't think we'll see problems on other platforms but please let
me know if I broke anyone.

llvm-svn: 245141

show more ...

Fix LLGS to enable read type watchpoints
http://reviews.llvm.org/D11902

llvm-svn: 244741

[LLGS] Spawned process handling cleanup

Summary:
This commit moves the m_spawned_pids member from the common LLGS/Platform class to the plaform
specific part. This enables us to remove LLGS code, wh

[LLGS] Spawned process handling cleanup

Summary:
This commit moves the m_spawned_pids member from the common LLGS/Platform class to the plaform
specific part. This enables us to remove LLGS code, which was attempting to manage the
m_spawned_pids contents, but at the same time making sure, there is only one debugged process. If
we ever want to do multi-process debugging, we will probably want to replace this with a set of
NativeProcessProtocolSP anyway. The only functional change is that support for
qKillSpawnedProcess packet is removed from LLGS, but this was not used there anyway (we have the
k packet for that).

Reviewers: ovyalov, clayborg

Subscribers: lldb-commits

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

llvm-svn: 243513

show more ...

[LLGS] Avoid bogus error message on process termination

Summary:
Handle_k was printing an error when killing a process because KillSpawnedProcess was expecting to
be asynchronously notified of the p

[LLGS] Avoid bogus error message on process termination

Summary:
Handle_k was printing an error when killing a process because KillSpawnedProcess was expecting to
be asynchronously notified of the process death, which no longer works, since we don't wait for
the process on a separate thread. However, the whole usage of KillSpawnedProcess is dubious here,
since it tries to be nice and terminate the process first with SIGTERM, which will not have the
intended effect on a ptraced process. I replace this code with a call to
NativeProcessProtocol::Kill, which does not suffer from these problems.

Reviewers: chaoren, ovyalov

Subscribers: lldb-commits

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

llvm-svn: 243397

show more ...

Add jstopinfo support to llgs

Summary:
This adds support for jstopinfo field of stop-reply packets. This field enables us to avoid
querying full thread stop data on most stops (see r242593 for more

Add jstopinfo support to llgs

Summary:
This adds support for jstopinfo field of stop-reply packets. This field enables us to avoid
querying full thread stop data on most stops (see r242593 for more details).

Reviewers: ovyalov, clayborg

Subscribers: lldb-commits

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

llvm-svn: 242997

show more ...

[NativeProcessLinux] Integrate MainLoop

Summary:
This commit integrates MainLoop into NativeProcessLinux. By registering a SIGCHLD handler with
the llgs main loop, we can get rid of the special moni

[NativeProcessLinux] Integrate MainLoop

Summary:
This commit integrates MainLoop into NativeProcessLinux. By registering a SIGCHLD handler with
the llgs main loop, we can get rid of the special monitor thread in NPL, which saves as a lot of
thread ping-pong when responding to client requests (e.g. qThreadInfo processing time has been
reduced by about 40%). It also makes the code simpler, IMHO.

Reviewers: ovyalov, clayborg, tberghammer, chaoren

Subscribers: lldb-commits

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

This is a resubmission of r242305 after it was reverted due to bad interactions with the stdio
thread.

llvm-svn: 242783

show more ...

[LLGS] Get rid of the stdio forwarding thread

Summary:
This commit removes the stdio forwarding thread in lldb-server in favor of a MainLoop callback.
As in some situations we need to forcibly flush

[LLGS] Get rid of the stdio forwarding thread

Summary:
This commit removes the stdio forwarding thread in lldb-server in favor of a MainLoop callback.
As in some situations we need to forcibly flush the stream ( => Read() is called from multiple
places) and we still have multiple threads, I have had to additionally protect the communication
instance with a mutex.

Reviewers: ovyalov, tberghammer

Subscribers: lldb-commits

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

llvm-svn: 242782

show more ...

[LLGS] Limit jThreadsInfo to only the most important registers for now

Summary:
It seems that reading of register data is the biggest bottleneck in LLGS at the moment. Sending
four registers instead

[LLGS] Limit jThreadsInfo to only the most important registers for now

Summary:
It seems that reading of register data is the biggest bottleneck in LLGS at the moment. Sending
four registers instead of the full GPR set increases the jThreadsInfo processing time about
6-fold. Until we figure out where is this time going, this commit limits the amount of data we
send to provide a more fluid debugging experience.

Reviewers: tberghammer, ovyalov

Subscribers: lldb-commits

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

llvm-svn: 242517

show more ...

Add jThreadsInfo support to lldb-server

Summary:
This commit adds initial support for the jThreadsInfo packet to lldb-server. The current
implementation does not expedite inferior memory. I have al

Add jThreadsInfo support to lldb-server

Summary:
This commit adds initial support for the jThreadsInfo packet to lldb-server. The current
implementation does not expedite inferior memory. I have also added a description of the new
packet to our protocol documentation (mostly taken from Greg's earlier commit message).

Reviewers: clayborg, ovyalov, tberghammer

Subscribers: lldb-commits

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

llvm-svn: 242402

show more ...

Revert "[NativeProcessLinux] Integrate MainLoop"

This seems to be causing major slowdows on the android buildbot. Reverting while I investigate.

llvm-svn: 242391

[NativeProcessLinux] Integrate MainLoop

Summary:
This commit integrates MainLoop into NativeProcessLinux. By registering a SIGCHLD handler with
the llgs main loop, we can get rid of the special moni

[NativeProcessLinux] Integrate MainLoop

Summary:
This commit integrates MainLoop into NativeProcessLinux. By registering a SIGCHLD handler with
the llgs main loop, we can get rid of the special monitor thread in NPL, which saves as a lot of
thread ping-pong when responding to client requests (e.g. qThreadInfo processing time has been
reduced by about 40%). It also makes the code simpler, IMHO.

Reviewers: ovyalov, clayborg, tberghammer, chaoren

Subscribers: lldb-commits

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

llvm-svn: 242305

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

Avoid going through Platform when creating a NativeProcessProtocol instance

Summary:
This commit avoids the Platform instance when spawning or attaching to a process in lldb-server.
Instead, I have

Avoid going through Platform when creating a NativeProcessProtocol instance

Summary:
This commit avoids the Platform instance when spawning or attaching to a process in lldb-server.
Instead, I have the server call a (static) method of NativeProcessProtocol directly. The reason
for this is that I believe that NativeProcessProtocol should be decoupled from the Platform
(after all, it always knows which platform it is running on, unlike the rest of lldb).
Additionally, the kind of platform actions a NativeProcessProtocol instance is likely to differ
greatly from the platform actions of the lldb client, so I think the separation makes sense.

After this, the only dependency NativeProcessLinux has on PlatformLinux is the ResolveExecutable
method, which needs additional refactoring.

This is a resubmit of r241672, after it was reverted due to build failueres on non-linux
platforms.

Reviewers: ovyalov, clayborg

Subscribers: lldb-commits

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

llvm-svn: 241796

show more ...

Revert r241672, which breaks the OS X build by introducing a dependency on
platform-specific symbols that are not implemented on OS X.

The build error that caused this is

Undefined symbols for arch

Revert r241672, which breaks the OS X build by introducing a dependency on
platform-specific symbols that are not implemented on OS X.

The build error that caused this is

Undefined symbols for architecture x86_64:
"lldb_private::NativeProcessProtocol::Attach(unsigned long long, lldb_private::NativeProcessProtocol::NativeDelegate&, std::__1::shared_ptr<lldb_private::NativeProcessProtocol>&)", referenced from:
lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS::AttachToProcess(unsigned long long) in liblldb-core.a(GDBRemoteCommunicationServerLLGS.o)
"lldb_private::NativeProcessProtocol::Launch(lldb_private::ProcessLaunchInfo&, lldb_private::NativeProcessProtocol::NativeDelegate&, std::__1::shared_ptr<lldb_private::NativeProcessProtocol>&)", referenced from:
lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS::LaunchProcess() in liblldb-core.a(GDBRemoteCommunicationServerLLGS.o)
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

llvm-svn: 241688

show more ...

Avoid going through Platform when creating a NativeProcessProtocol instance

Summary:
This commit avoids the Platform instance when spawning or attaching to a process in lldb-server.
Instead, I have

Avoid going through Platform when creating a NativeProcessProtocol instance

Summary:
This commit avoids the Platform instance when spawning or attaching to a process in lldb-server.
Instead, I have the server call a (static) method of NativeProcessProtocol directly. The reason
for this is that I believe that NativeProcessProtocol should be decoupled from the Platform
(after all, it always knows which platform it is running on, unlike the rest of lldb).
Additionally, the kind of platform actions a NativeProcessProtocol instance is likely to differ
greatly from the platform actions of the lldb client, so I think the separation makes sense.

After this, the only dependency NativeProcessLinux has on PlatformLinux is the ResolveExecutable
method, which needs additional refactoring.

Reviewers: ovyalov, clayborg

Subscribers: lldb-commits

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

llvm-svn: 241672

show more ...

Fetch object file load address if it isn't specified by the linker

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

llvm-svn: 240052