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
Since interaction with the python interpreter is moving towards
being more isolated, we won't be able to include this header from
normal files anymore, all includes of it should be localized to
the python library which will live under source/bindings/API/Python
after a future patch.
None of the files that were including this header actually depended
on it anyway, so it was just a dead include in every single instance.
llvm-svn: 238581
This change also get rid of an unused Debugger instance in
GDBRemoteCommunicationServerLLGS and the command interpreter from
lldb-platform what was used only for enabling logging.
Differential revision: http://reviews.llvm.org/D9876
llvm-svn: 238319
If binding to port 0 is selected, the actual port is printed.
This improves the reliability of platform startup by ensuring that
a free port can be found.
TEST PLAN
./lldb-server platform --listen *:0
Listening for a connection from <port-number>...
Will appear on stdout (with other stuff potentially)
llvm-svn: 238173
lldb-platform's listener socket only had a backlog of one connection.
That means that if more than one client connected simultaneously, the
connection would be refused. The test suite can be run remotely with
dozens of threads connecting simultaneously. Raised this limit to 100
to effectively eliminate lost connections.
Test Plan:
run tests against a remote target
Differential Revision: http://reviews.llvm.org/D8696
llvm-svn: 233652
lldb-server server process was holding on to a connection to every
client that connected. This continued until the process hit it's
file limit and exited.
lldb-server p --listen *:5432 --server
run remote tests against that server more than 1000 times
Differential Revision: http://reviews.llvm.org/D8697
llvm-svn: 233651
Adds the --server argument to lldb-server platform which when specified will allow multiple simultaneous connections by forking off to handle each individual connection. This will allow us to run the remote tests in parallel.
Test Plan:
Run: lldb-server platform --listen *:1234 --server
Connect from multiple lldb clients simultaneously.
I will also test running the test suite remotely with multiple simultaneous jobs.
Differential Revision: http://reviews.llvm.org/D8452
llvm-svn: 233185
So that we don't have to update every single #include in the entire
codebase to #include this new header (which used to get included by
lldb-private-log.h, we automatically #include "Logging.h" from
within "Log.h".
llvm-svn: 232653
Separate out the necessary component initialization for lldb-server such that the linker can greatly reduce the binary size. With this patch the size of lldb-server on my 64 bit linux release build drops from 46MB to 26MB.
Differential Revision: http://reviews.llvm.org/D7880
llvm-svn: 230963
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
Oleksiy Vyalov