summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServerLLGS.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Remove platform plugins from lldb-serverPavel Labath2016-06-291-5/+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-21/+20
| | | | | | | | | | 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
* Add -Wimplicit-fallthrough command line option to clang inJason Molenda2016-02-161-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Improve the functionality of JSONNumberTamas Berghammer2015-12-041-1/+1
| | | | | | | | | * 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
* [LLGS] Don't forward I/O when process is stoppedPavel Labath2015-11-271-27/+42
| | | | | | | | | | | | | | | | | | | | | 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] Send PC of every thread along in the stop-reply packetPavel Labath2015-10-261-14/+14
| | | | | | | | 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
* lldb-server: add support for binary memory readsPavel Labath2015-10-141-5/+15
| | | | | | | | | | | | | | | | | 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
* Clean up register naming conventions inside lldb. Jason Molenda2015-09-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "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
* A messy bit of cleanup: Move towards more descriptive namesJason Molenda2015-08-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix LLGS to enable read type watchpointsOmair Javaid2015-08-121-5/+4
| | | | | | http://reviews.llvm.org/D11902 llvm-svn: 244741
* [LLGS] Spawned process handling cleanupPavel Labath2015-07-291-91/+26
| | | | | | | | | | | | | | | | | | | 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
* [LLGS] Avoid bogus error message on process terminationPavel Labath2015-07-281-15/+10
| | | | | | | | | | | | | | | | | | 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
* Add jstopinfo support to llgsPavel Labath2015-07-231-63/+114
| | | | | | | | | | | | | | 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
* [NativeProcessLinux] Integrate MainLoopPavel Labath2015-07-211-15/+2
| | | | | | | | | | | | | | | | | | | 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-58/+58
| | | | | | | | | | | | | | | | 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
* [LLGS] Limit jThreadsInfo to only the most important registers for nowPavel Labath2015-07-171-5/+20
| | | | | | | | | | | | | | | | 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
* Add jThreadsInfo support to lldb-serverPavel Labath2015-07-161-28/+167
| | | | | | | | | | | | | | | 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-2/+15
| | | | | | This seems to be causing major slowdows on the android buildbot. Reverting while I investigate. llvm-svn: 242391
* [NativeProcessLinux] Integrate MainLoopPavel Labath2015-07-151-15/+2
| | | | | | | | | | | | | | | | 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-3/+57
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Avoid going through Platform when creating a NativeProcessProtocol instancePavel Labath2015-07-091-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | 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
* Revert r241672, which breaks the OS X build by introducing a dependency onSean Callanan2015-07-081-2/+2
| | | | | | | | | | | | | | | | 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
* Avoid going through Platform when creating a NativeProcessProtocol instancePavel Labath2015-07-081-2/+2
| | | | | | | | | | | | | | | | | | | | | 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
* Fetch object file load address if it isn't specified by the linkerTamas Berghammer2015-06-181-0/+31
| | | | | | Differential revision: http://reviews.llvm.org/D10490 llvm-svn: 240052
* Refactor many file functions to use FileSpec over strings.Chaoren Lin2015-05-291-4/+4
| | | | | | | | | | | | | | | | | Summary: This should solve the issue of sending denormalized paths over gdb-remote if we stick to GetPath(false) in GDBRemoteCommunicationClient, and let the server handle any denormalization. Reviewers: ovyalov, zturner, vharron, clayborg Reviewed By: clayborg Subscribers: tberghammer, emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D9728 llvm-svn: 238604
* Make log options uniform betwwen lldb-platform and lldb-gdbserverTamas Berghammer2015-05-271-6/+2
| | | | | | | | | | 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
* Fix a few compile warningsIlia K2015-05-151-2/+2
| | | | llvm-svn: 237425
* Remove trap code from disassembly.Chaoren Lin2015-04-291-5/+5
| | | | | | | | | | | | | | | | | | | | Summary: NativeProcessProtocol uses ReadMemory internally for setting/checking breakpoints but also for generic memory reads (Handle_m), this change adds a ReadMemoryWithoutTrap for that purpose. Also fixes a bunch of misuses of addr_t as size/length. Test Plan: `disassemble` no longer shows the trap code. Reviewers: jingham, vharron, clayborg Reviewed By: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D9330 llvm-svn: 236132
* Fixed remote failures in TestCPP11EnumTypes, probably othersVince Harron2015-04-151-0/+5
| | | | | | | | | | | | | | | Typically, LLGS only sends stdout/stderr notifications when the inferior process is running. Because LLGS reads stdout from the process in a separate thread, sometimes these stdout notifications can be received after the server has sent a thread stop message. The host isn't expecting stdout to be generated by the target after a stop message and these messages interfere with the host's request/ response paradigm. Differential Revision: http://reviews.llvm.org/D9024 llvm-svn: 234995
* Move several plugin to its own namespaceTamas Berghammer2015-03-311-23/+24
| | | | | | | | | | | | | 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/+17
| | | | | | | | | | | | | 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
* Don't close pseudo terminal master file descriptor on EOFTamas Berghammer2015-03-191-0/+1
| | | | | | | | | | | | | Some application on Linux an all application on android close stdout and stderr during the libc exit stage. Previously the master file descriptor of the pseudo terminal used to communicate with the inferior was closed on an EOF causing a race condition and a possible SIGHUP on process exit. After this change the master file descriptor will be closed by the destructor of the GDBRemoteCommunicationServerLLGS class. Differential revision: http://reviews.llvm.org/D8436 llvm-svn: 232724
* Remove unused handler registreation from GDBRemoteCommunicationServerLLGSTamas Berghammer2015-03-171-2/+0
| | | | llvm-svn: 232488
* Fix errors building on linux.Zachary Turner2015-03-031-0/+1
| | | | llvm-svn: 231169
* Further reduce the header footprint of Process.hZachary Turner2015-03-031-0/+1
| | | | | | | No functional change here, only deletes unnecessary headers and moves one function's body from the .h file to the .cpp. llvm-svn: 231145
* Prevent LLGS from crashing when exiting - make NativeProcessLinux to wait ↵Oleksiy Vyalov2015-02-191-0/+7
| | | | | | | | until ThreadStateCoordinator is fully stopped before entering ~NativeProcessLinux. http://reviews.llvm.org/D7692 llvm-svn: 229875
* Send default register number instead of GDB register number in StopReplyPacket.Chaoren Lin2015-02-171-19/+5
| | | | | | | | | | | | | | | | Summary: Using GDB register numbers confuses ProcessGDBRemote since the rest of LLGS (qRegisterInfo, p, P) uses the default register numbers instead. Test Plan: dosep.py --options --arch x86 ... Reviewers: ovyalov, vharron, sivachandra Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D7635 llvm-svn: 229505
* Fix small assignment mistake.Chaoren Lin2015-02-171-2/+2
| | | | llvm-svn: 229503
* Fix TestProcessIO.py when run against a remote targetVince Harron2015-02-131-28/+29
| | | | | | | | | | | | | 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/+2742
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