summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.h
Commit message (Collapse)AuthorAgeFilesLines
* llgs: Propagate the environment when launching the inferior from command linePavel Labath2017-12-181-26/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: We were failing to propagate the environment when lldb-server was started with a pre-loaded process (e.g.: lldb-server gdbserver -- inferior --inferior_args) This patch makes sure the environment is propagated. Instead of adding a new GDBRemoteCommunicationServerLLGS::SetLaunchEnvironment function to complement SetLaunchArgs and SetLaunchFlags, I replace these with a more generic SetLaunchInfo, which can be used to set any launch-related property. The accompanying test also verifies that the server correctly terminates the connection after sending the exit packet (specifically, that it does not send the exit packet twice). Reviewers: clayborg, eugene Subscribers: lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D41070 llvm-svn: 320984
* Remove shared_pointer from NativeThreadProtocolPavel Labath2017-10-171-1/+1
| | | | | | | | | | | | | | | | | | | Summary: The NativeThread class is useless without the containing process (and in some places it is already assuming the process is always around). This makes it clear that the NativeProcessProtocol is the object owning the threads, and makes the destruction order deterministic (first threads, then process). The NativeProcess is the only thing holding a thread unique_ptr, and methods that used to hand out thread shared pointers now return raw pointers or references. Reviewers: krytarowski, eugene Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D35618 llvm-svn: 316007
* Remove shared pointer from NativeProcessProtocolPavel Labath2017-07-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The usage of shared_from_this forces us to separate construction and initialization phases, because shared_from_this() is not available in the constructor (or destructor). The shared semantics are not necessary, as we always have a clear owner of the native process class (GDBRemoteCommunicationServerLLDB object). Even if we need shared semantics in the future (which I think we should strongly avoid), reverting this will not be necessary -- the owners can still easily store the native process object in a shared pointer if they really want to -- this just prevents the knowledge of that from leaking into the class implementation. After this a NativeThread object will hold a reference to the parent process (instead of a weak_ptr) -- having a process instance always available allows us to simplify some logic in this class (some of it was already simplified because we were asserting that the process is available, but this makes it obvious). Reviewers: krytarowski, eugene, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D35123 llvm-svn: 308282
* Add a NativeProcessProtocol Factory classPavel Labath2017-07-071-6/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This replaces the static functions used for creating NativeProcessProtocol instances with a factory pattern, and modernizes the interface of the new class in the process -- I use llvm::Expected instead of the Status+value combo. I also move some of the common code (like the Delegate registration into the base class). The new arrangement has multiple benefits: - it removes the NativeProcess*** dependency from Process/gdb-remote (which for example means that liblldb no longer pulls in this code). - it enables unit testing of the GDBRemoteCommunicationServerLLGS class (by providing a mock Native Process). - serves as another example on how to use the llvm::Expected class (I couldn't get rid of the Initialize-type functions completely here because of the use of shared_from_this, but that's the next thing on my list here) Tests still pass on Linux and I've made sure NetBSD compiles after this. Reviewers: zturner, eugene, krytarowski Subscribers: srhines, lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D33778 llvm-svn: 307390
* Implementation of remote packets for Trace data.Ravitheja Addepally2017-05-261-0/+8
| | | | | | | | | | | | | | | | | | Summary: The changes consist of new packets for trace manipulation and trace collection. The new packets are also documented. The packets are capable of providing custom trace specific parameters to start tracing and also retrieve such configuration from the server. Reviewers: clayborg, lldb-commits, tberghammer, labath, zturner Reviewed By: clayborg, labath Subscribers: krytarowski, lldb-commits Differential Revision: https://reviews.llvm.org/D32585 llvm-svn: 303972
* Rename Error -> Status.Zachary Turner2017-05-121-10/+10
| | | | | | | | | | | | | | | This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
* Move GetAuxvData from Host to relevant process pluginsPavel Labath2017-03-171-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: GetAuxvData was causing dependencies from host to target and linux process modules. It also does not fit netbsd use case, as there we can only read the auxiliary vector with ptrace, which is better done in the process plugin, with the other ptrace calls. I resolve these issues by moving the freebsd and linux versions into the relevant process plugins. In case of linux, this required adding an interface in NativeProcessProtocol. The empty definitions on other platforms can simply be removed. To get the code compiling I had to add ProcessGdbRemote -> ProcessLinux dependency, which was not caught before because we depended on it transitively. Reviewers: zturner, emaste Subscribers: srhines, mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D31031 llvm-svn: 298066
* Implement QPassSignals GDB package in lldb-serverPavel Labath2017-02-241-0/+2
| | | | | | | | | | | | | | | Summary: QPassSignals package allows lldb client to tell lldb-server to ignore certain types of signals and re-inject them back to inferior without stopping execution. Reviewers: jmajors, labath Subscribers: danalbert, srhines, emaste, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D30286 Author: Eugene Zemtsov <ezemtsov@google.com> llvm-svn: 296101
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-213/+151
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* Remove platform plugins from lldb-serverPavel Labath2016-06-291-2/+1
| | | | | | | | | | | | | | | | | | | 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
* remove use of Mutex in favour of std::{,recursive_}mutexSaleem Abdulrasool2016-05-181-3/+3
| | | | | | | | | | 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
* [LLGS] Don't forward I/O when process is stoppedPavel Labath2015-11-271-1/+3
| | | | | | | | | | | | | | | | | | | | | 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
* lldb-server: add support for binary memory readsPavel Labath2015-10-141-1/+2
| | | | | | | | | | | | | | | | | 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
* [LLGS] Spawned process handling cleanupPavel Labath2015-07-291-10/+0
| | | | | | | | | | | | | | | | | | | 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
* [NativeProcessLinux] Integrate MainLoopPavel Labath2015-07-211-3/+0
| | | | | | | | | | | | | | | | | | | 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
* [LLGS] Get rid of the stdio forwarding threadPavel Labath2015-07-211-8/+12
| | | | | | | | | | | | | | | | 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
* Add jThreadsInfo support to lldb-serverPavel Labath2015-07-161-0/+3
| | | | | | | | | | | | | | | 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
* Revert "[NativeProcessLinux] Integrate MainLoop"Pavel Labath2015-07-161-0/+3
| | | | | | This seems to be causing major slowdows on the android buildbot. Reverting while I investigate. llvm-svn: 242391
* [NativeProcessLinux] Integrate MainLoopPavel Labath2015-07-151-3/+0
| | | | | | | | | | | | | | | | 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
* Introduce a MainLoop class and switch llgs to use itPavel Labath2015-07-131-2/+12
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fetch object file load address if it isn't specified by the linkerTamas Berghammer2015-06-181-0/+3
| | | | | | Differential revision: http://reviews.llvm.org/D10490 llvm-svn: 240052
* Make log options uniform betwwen lldb-platform and lldb-gdbserverTamas Berghammer2015-05-271-3/+1
| | | | | | | | | | 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
* Move several plugin to its own namespaceTamas Berghammer2015-03-311-19/+26
| | | | | | | | | | | | | 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
* Fetch module specification from remote process alsoTamas Berghammer2015-03-241-0/+3
| | | | | | | | | | | | | Previously the remote module sepcification was fetched only from the remote platform. With this CL if we have a remote process then we ask it if it have any information from a given module. It is required because on android the dynamic linker only reports the name of the SO file and the platform can't always find it without a full path (the process can do it based on /proc/<pid>/maps). Differential revision: http://reviews.llvm.org/D8547 llvm-svn: 233061
* Fix TestProcessIO.py when run against a remote targetVince Harron2015-02-131-3/+0
| | | | | | | | | | | | | Fixed test case to copy redirected stdout/stderr files from remote target to host llgs wasn't bothering to put the pty master file handle in the right place if stdout/stderr were redirected to a file. It is still needed for stdin. Corrected some log message text llvm-svn: 229141
* Separate monolithic GDBRemoteCommunicationServer class into 4 partTamas Berghammer2015-02-111-0/+299
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
OpenPOWER on IntegriCloud