summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/gdb-remote
Commit message (Collapse)AuthorAgeFilesLines
* Pass socket scheme as part of debug server listen URL.Oleksiy Vyalov2016-02-031-0/+1
| | | | | | http://reviews.llvm.org/D16861 llvm-svn: 259714
* Fix single-stepping onto a breakpointPavel Labath2016-02-021-12/+3
| | | | | | | | | | | | | | | Summary: r259344 introduced a bug, where we fail to perform a single step, when the instruction we are stepping onto contains a breakpoint which is not valid for this thread. This fixes the problem and add a test case. Reviewers: tberghammer, emaste Subscribers: abhishek.aggarwal, lldb-commits, emaste Differential Revision: http://reviews.llvm.org/D16767 llvm-svn: 259488
* Set correct ThreadStopInfo in case of trace eventAbhishek Aggarwal2016-02-011-1/+21
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: - The patch solves Bug 23478 and Bug 19311. Resolving Bug 23478 also resolves Bug 23039. Correct ThreadStopInfo is set for Linux and FreeBSD platforms. - Summary: When a trace event is reported, we need to check whether the trace event lands at a breakpoint site. If it lands at a breakpoint site then set the thread's StopInfo with the reason 'breakpoint'. Else, set the reason to be 'Trace'. Change-Id: I0af9765e782fd74bc0cead41548486009f8abb87 Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com> Reviewers: jingham, emaste, lldb-commits, clayborg, ovyalov Subscribers: emaste Differential Revision: http://reviews.llvm.org/D16720 llvm-svn: 259344
* Remove autoconf support from source directories.Eugene Zelenko2016-01-281-14/+0
| | | | | | Differential revision: http://reviews.llvm.org/D16662 llvm-svn: 259098
* A while back in revison 244716 we added support for getting the host OS ↵Greg Clayton2016-01-281-1/+2
| | | | | | | | version info from debugserver. We added keys to "qHostInfo" that were "osmajor", "osminor" and "ospatch", but no one ever parsed those, so I am removing them from debugserver. We accidentally also added a "version" key to qHostInfo instead of "os_version". So now we need to support both "version" and "os_version" in qHostInfo since we have debugserver binaries out in the wild that support this old packet type. I have updated debugserver ot use the correct "os_version" for future compatability or correctness. <rdar://problem/24378699> llvm-svn: 259003
* Add a small refinement to the qSymbol:: support in lldb.Jason Molenda2016-01-132-1/+48
| | | | | | | | | | | | | | | This is a packet which allows the remote gdb stub to ask for the address of a symbol in the process. lldb sends the packet (offering to provide addresses for symbol names) after every solib loaded. I changed lldb so that once the stub has indicated that it doesn't need any more symbol addresses, lldb will stop sending the qSymbol:: packet on new solib loads. This can yield a performance benefit over slower communication links when there are many solibs involved. <rdar://problem/23310049> llvm-svn: 257569
* Increase use of svr4 packets to improve performance on POSIX remotesStephane Sezer2016-01-122-122/+19
| | | | | | | | | | | | | | | | | | | | Summary: Allows the remote to enumerate the link map when adding and removing shared libraries, so that lldb doesn't need to read it manually from the remote's memory. This provides very large speedups (on the order of 50%) in total startup time when using the ds2 remote on android or Tizen devices. Reviewers: ADodds, tberghammer, tfiala Subscribers: tberghammer, sas, danalbert, llvm-commits, srhines Differential Revision: http://reviews.llvm.org/D16004 Change by Francis Ricci <fjricci@fb.com> llvm-svn: 257502
* Changes to lldb and debugserver to reduce extraneous memory readsJason Molenda2016-01-124-19/+152
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | at each public stop to improve performance a bit. Most of the information lldb needed was already in the jThreadsInfo response; complete that information and catch a few cases where we could still fall back to getting the information via discrete memory reads. debugserver adds 'associated_with_dispatch_queue' and 'dispatch_queue_t keys to the jThreadsInfo response for all the threads. lldb needs the dispatch_queue_t value. And associated_with_dispatch_queue helps to identify which threads definitively don't have any queue information so lldb doesn't try to do memory reads to get that information just because it was absent in the jThreadsInfo response. Remove the queue information from the questionmark (T) packet. We'll get the information for all threads via the jThreadsInfo response - sending the information for the stopping thread (on all the private stops, plus the less frequent public stop) was unnecessary information being sent over the wire. SystemRuntimeMacOSX will try to get information about queues by asking the Threads for them, instead of reading memory. ProcessGDBRemote changes to recognize the new keys being sent in the jThreadsInfo response. Changes to ThreadGDBRemote to track the new information. Also, when a thread is marked as definitively not associated with a libdispatch queue, don't fall back to the system runtime to try memory reads to find the queue name / kind / ID etc. <rdar://problem/23309359> llvm-svn: 257453
* Change the key name for the libdispatch queue serial number fromJason Molenda2016-01-081-12/+12
| | | | | | | | | "qserial" to "qserialnum" because "qserial" looks a lot like the queue type (either 'serial' or 'concurrent') and can be confusing to read through. debugserver passes these up either in the questionmark ("T") packet, or in the response to the jThreadsInfo packet. llvm-svn: 257121
* Make sure we don't send qModuleInfo packets unnecessarily.Stephane Sezer2016-01-082-1/+13
| | | | | | | | | | | | | | Summary: Some debug servers don't support it so there's no point in spamming this. Reviewers: clayborg Subscribers: fjricci, lldb-commits Differential Revision: http://reviews.llvm.org/D15972 llvm-svn: 257116
* Strip trailing whitespaceEd Maste2016-01-041-144/+144
| | | | | | | | (There are changes in the copies of these four files in the FreeBSD base system, and I've changed these ones to reduce gratuitous diffs in future imports.) llvm-svn: 256723
* The lldb side changes to go along with r255711 where a newJason Molenda2015-12-186-0/+144
| | | | | | | | | | | | | | | | | | | | | | "thread-pcs" key is added to the T (questionmark) packet in gdb-remote protocol so that lldb doesn't need to query the pc values of every thread before it resumes a process. The only odd part with this is that I'm sending the pc values in big endian order, so we need to know the endianness of the remote process before we can use them. All other register values in gdb-remote protocol are sent in native-endian format so this requirement doesn't exist. This addition is a performance enhancement -- lldb will fall back to querying the pc of each thread individually if it needs to -- so when we don't have the byte order for the process yet, we don't use these values. Practically speaking, the only way I've been able to elicit this condition is for the first T packet when we attach to a process. <rdar://problem/21963031> llvm-svn: 255942
* Fix MSVC build after rL255016Tamas Berghammer2015-12-081-2/+4
| | | | llvm-svn: 255017
* Modify "platform connect" to connect to processes as wellTamas Berghammer2015-12-086-66/+183
| | | | | | | | | | | | | | | | | | | | | | | | The standard remote debugging workflow with gdb is to start the application on the remote host under gdbserver (e.g.: gdbserver :5039 a.out) and then connect to it with gdb. The same workflow is supported by debugserver/lldb-gdbserver with a very similar syntax but to access all features of lldb we need to be connected also to an lldb-platform instance running on the target. Before this change this had to be done manually with starting a separate lldb-platform on the target machine and then connecting to it with lldb before connecting to the process. This change modifies the behavior of "platform connect" with automatically connecting to the process instance if it was started by the remote platform. With this command replacing gdbserver in a gdb based worflow is usually as simple as replacing the command to execute gdbserver with executing lldb-platform. Differential revision: http://reviews.llvm.org/D14952 llvm-svn: 255016
* Fill in the generic register kind if in AugmentRegisterInfoViaABI if it is ↵Greg Clayton2015-12-041-4/+9
| | | | | | available. llvm-svn: 254743
* 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
* [LLDB][MIPS] fix watchpoint searched on client side for same masked variablesMohit K. Bhakkad2015-12-021-3/+6
| | | | | | | | Reviewers: clayborg. Subscribers: jaydeep, bhushan, sagar, nitesh.jain,lldb-commits. Differential Revision: http://reviews.llvm.org/D15106 llvm-svn: 254522
* [LLGS] Don't forward I/O when process is stoppedPavel Labath2015-11-272-28/+45
| | | | | | | | | | | | | | | | | | | | | 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
* Prevent ProcessGDBRemote from launching local debug server in case of remote ↵Oleksiy Vyalov2015-11-232-36/+31
| | | | | | | | debug server connection failure. http://reviews.llvm.org/D14895 llvm-svn: 253906
* Avoid sending bare '*' and '}' in an lldb-server packetTim Northover2015-11-091-0/+1
| | | | | | | | | | They get treated as special RLE encoding symbols and packets get corrupted. Most other packet types already know about this apparently, but QEnvironment missed these two. Should fix PR25300. llvm-svn: 252521
* Make lldb::endian::InlHostByteOrder() private.Bruce Mitchener2015-11-073-12/+12
| | | | | | | | | | | | | | | | | | Summary: Since this is within the lldb namespace, the compiler tries to export a symbol for it. Unfortunately, since it is inlined, the symbol is hidden and this results in a mess of warnings when building on OS X with cmake. Moving it to the lldb_private namespace eliminates that problem. Reviewers: clayborg Subscribers: emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D14417 llvm-svn: 252396
* Use Process::IsAlive instead of just checking for eStateExited.Jason Molenda2015-11-051-4/+4
| | | | | | Two minor tweaks to GetLoadedDynamicLibrariesInfos. llvm-svn: 252242
* GDBRemoteCommunicationClient::SendEnvironmentPacket should use the hex-encodedJason Molenda2015-11-051-0/+1
| | | | | | env packet if the '*' character used for run length encoding is present. llvm-svn: 252239
* Let the process help figure out the Host OS if nobody elseJim Ingham2015-11-052-0/+17
| | | | | | can figure it out. llvm-svn: 252224
* Fix a deadlock when connecting to a remote GDB server that might not support ↵Greg Clayton2015-11-031-16/+20
| | | | | | | | all packets that lldb-server or debugserver supports. The issue was the m_last_stop_packet_mutex mutex was being held by another thread and it was deadlocking getting the thread list. We now try to lock the m_last_stop_packet_mutex, and only continue if we successfully lock it. Else we fall back to qfThreadInfo/qsThreadInfo. <rdar://problem/22140023> llvm-svn: 252005
* Make lldb-gdbserver to take explicit socket scheme as command line argument.Oleksiy Vyalov2015-10-282-2/+7
| | | | | | http://reviews.llvm.org/D14126 llvm-svn: 251547
* Fix race condition in process resumePavel Labath2015-10-271-1/+7
| | | | | | | | | | | | | | | | | | Summary: Gdb-remote's async thread sent out the eBroadcastBitRunPacketSent message *before* actually sending out the continue packet. Since it's this message the actually triggers the public state transition, it could happen (and it did happen in TestAttachResume, which does an "process interrupt" right after a continue) that we attempt to stop the inferior before it was actually started (which obviously did not end well). This fixes the problem by moving the broadcast after the packet was actually sent. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D14083 llvm-svn: 251399
* [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
* Revert r251167 in source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp to ↵Eugene Zelenko2015-10-241-32/+84
| | | | | | fix MSVC builds failures. llvm-svn: 251170
* Fix Clang-tidy modernize-use-override warnings in some files in ↵Eugene Zelenko2015-10-249-270/+177
| | | | | | source/Plugins; other minor fixes. llvm-svn: 251167
* Add domain socket support to gdb-remote protocol and lldb-server.Oleksiy Vyalov2015-10-217-64/+149
| | | | | | http://reviews.llvm.org/D13881 llvm-svn: 250933
* Allow LLDB.framework to locate debugserver even when it doesn't exist in the ↵Greg Clayton2015-10-194-9/+22
| | | | | | | | | | LLDB.framework. This allows open source MacOSX clients to not have to build debugserver and the current LLDB can find debugserver inside the selected Xcode.app on your system. <rdar://problem/23167253> llvm-svn: 250735
* Silence -Wqual-cast warnings from GCC 5.2Saleem Abdulrasool2015-10-181-1/+2
| | | | | | | | There were a number of const qualifiers being cast away which caused warnings. This cluttered the output hiding real errors. Silence them by explicit casting. NFC. llvm-svn: 250662
* In r240466, when Greg added the jThreadsInfo packet, he accidentallyJason Molenda2015-10-151-1/+0
| | | | | | | | | | | | | | disabled the use of the jThreadGetExtendedInfo packet which is used to retrieve additional information about a thread, such as the QoS setting for that thread on darwin systems. Re-enable the use of the jThreadGetExtendedInfo packet, and add some quick tests to the TestQueues mac test case which will verify that we can retrieve the QoS names for these test threads. <rdar://problem/22925096> llvm-svn: 250364
* Make uses of /dev/null portable across OSes.Zachary Turner2015-10-141-3/+4
| | | | | | | | | Most platforms have "/dev/null". Windows has "nul". Instead of hardcoding the string /dev/null at various places, make a constant that contains the correct value depending on the platform, and use that everywhere instead. llvm-svn: 250331
* lldb-server: add support for binary memory readsPavel Labath2015-10-143-14/+19
| | | | | | | | | | | | | | | | | 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
* [LLDB] Adding mips32 in the list of archs with ↵Mohit K. Bhakkad2015-10-141-1/+3
| | | | | | watchpoint_exceptions_received=before llvm-svn: 250272
* [LLDB][MIPS] fix watchpoint searched on client side for same masked variablesMohit K. Bhakkad2015-10-091-0/+2
| | | | | | | | Reviewers: clayborg, jingham. Subscribers: jaydeep, bhushan, sagar, nitesh.jain, brucem,lldb-commits. Differential Revision: http://reviews.llvm.org/D13548 llvm-svn: 249837
* A small fixup needed for debugserver to work nativelyJason Molenda2015-09-221-61/+64
| | | | | | | | | | | | | | | | | on iOS devices; fallout from Vince's cleanups made in r237218 back in May. iOS native lldbs will call StartDebugserverProcess() with a random port # (see ProcessGDBRemote::LaunchAndConnectToDebugserver) and neither side of this conditional expression should be followed in that case. I added an "if (in_port == 0) { ..." check around the entire if/then/else and indented the block of code so the diff looks larger than it really is. <rdar://problem/21712643> llvm-svn: 248343
* [LLDB][MIPS] Debug bare-iron targets lacking support for qC /qfThreadInfoJaydeep Patil2015-09-181-0/+33
| | | | | | | | | | | SUMMARY: Using response.IsUnsupportedResponse instead of !response.IsNormalResponse(). Reviewers: clayborg, labath Subscribers: nitesh.jain, mohit.bhakkad, sagar, bhushan and lldb-commits Differential Revision: http://reviews.llvm.org/D12876 llvm-svn: 247968
* Fix LLDB RSP client to decode '$O' packets incorrectlyDawn Perchik2015-09-171-3/+7
| | | | | | | | | | | | Character with ASCII code 0 is incorrectly treated by LLDB as the end of RSP packet. The left of the debugger server output is silently ignored. Patch from evgeny.leviant@gmail.com Reviewed by: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12523 llvm-svn: 247908
* Add an OperatingSystem plugin to support goroutinesRyan Brown2015-09-161-0/+4
| | | | | | | | | | The Go runtime schedules user level threads (goroutines) across real threads. This adds an OS plugin to create memory threads for goroutines. It supports the 1.4 and 1.5 go runtime. Differential Revision: http://reviews.llvm.org/D5871 llvm-svn: 247852
* Revert "[LLDB][MIPS] Debug bare-iron targets lacking support for qC ↵Pavel Labath2015-09-161-33/+0
| | | | | | | | /qfThreadInfo" This reverts commit r247773, because it breaks remote debugging support for lldb-server. llvm-svn: 247783
* [LLDB][MIPS] Debug bare-iron targets lacking support for qC /qfThreadInfoJaydeep Patil2015-09-161-0/+33
| | | | | | | | | | | | | | SUMMARY: Refer to http://lists.llvm.org/pipermail/lldb-dev/2015-August/008024.html for discussion on this topic. Bare-iron target like YAMON gdb-stub does not support qProcessInfo, qC, qfThreadInfo, Hg and Hc packets. Reply from ? packet is as simple as S05. There is no packet which gives us process or threads information. In such cases, assume pid=tid=1. Reviewers: clayborg Subscribers: nitesh.jain, mohit.bhakkad, sagar, bhushan and lldb-commits Differential Revision: http://reviews.llvm.org/D12876 llvm-svn: 247773
* Clean up register naming conventions inside lldb. Jason Molenda2015-09-153-121/+119
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "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
* When lldb gets the register definitions from the response of aJason Molenda2015-09-091-4/+37
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | qXfer:features:read:target.xml packet, or via the plugin.process.gdb-remote.target-definition-file setting, if the register definition doesn't give us eh_frame or DWARF register numbers for that register, try to get that information from the ABI plugin. The DWARF/eh_frame register numbers are defined in the ABI standardization documents - so getting this from the ABI plugin is reasonable. There's little value in having the remote stub inform us of this generic information, as long as we can all agree on the names of the registers. There's some additional information we could get from the ABI. For instance, on ABIs where function arguments are passed in registers, lldb defines alternate names like "arg1", "arg2", "arg3" for these registers so they can be referred to that way by the user. We could get this from the ABI if the remote stub doesn't provide that. That may be something worth doing in the future - but for now, I'm keeping this a little more minimal. Thinking about this, what we want/need from the remote stub at a minimum are: 1. The names of the register 2. The number that the stub will use to refer to the register with the p/P packets and in the ? response packets (T/S) where expedited register values are provided 3. The size of the register in bytes (nice to have, to remove any doubt) 4. The offset of the register in the g/G packet if we're going to use that for reading/writing registers. debugserver traditionally provides a lot more information in addition to this via the qRegisterInfo packet, and debugserver augments its response to the qXfer:features:read:target.xml query to include this information. Including: DWARF regnum, eh_frame regnum, stabs regnum, encoding (ieee754, Uint, Vector, Sint), format (hex, unsigned, pointer, vectorof*, float), registers that should be marked as invalid if this register is modified, and registers that contain this register. We might want to get all of this from the ABI - I'm not convinced that it makes sense for the remote stub to provide any of these details, as long as the ABI and remote stub can agree on register names. Anyway, start with eh_frame and DWARF coming from the ABI if they're not provided by the remote stub. We can look at doing more in the future. <rdar://problem/22566585> llvm-svn: 247121
* A change I'm open to reverting if there is disagreement:Jason Molenda2015-09-091-1/+3
| | | | | | | | | | | | | | | | | | | When lldb receives a gdb-remote protocol packet that has nonprintable characters, it will print the packet in gdb-remote logging with binary-hex encoding so we don't dump random 8-bit characters into the packet log. I'm changing this check to allow whitespace characters (newlines, linefeeds, tabs) to be printed if those are the only non-printable characters in the packet. This is primarily to get the response to the qXfer:features:read:target.xml packet to show up in the packet logs in human readable form. Right now we just get a dozen kilobytes of hex-ascii and it's hard to figure out what register number scheme is being used. llvm-svn: 247120
* Fix deadlock while attaching to inferiorsPavel Labath2015-09-032-148/+159
| | | | | | | | | | | | | | | | | | | | Summary: There was a race condition in the AsyncThread, where we would end up sending a vAttach notification to the thread before it got a chance set up its listener (this can be reproduced by adding a sleep() at the very beginning of ProcessGDBRemote::AsyncThread()). This event would then get lost and we LLDB would deadlock. I fix this by setting up the listener early on, in the ProcessGDBRemote constructor. This should improve the stability of all attach tests. For now, I am removing XTIMEOUT from TestAttachResume, and will watch the buildbots for signs of trouble. Reviewers: clayborg, ovyalov Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12552 llvm-svn: 246756
* [cmake] Remove LLVM_NO_RTTI.Bruce Mitchener2015-09-031-3/+1
| | | | | | | | | | | | | | Summary: This doesn't exist in other LLVM projects any longer and doesn't do anything. Reviewers: chaoren, labath Subscribers: emaste, tberghammer, lldb-commits, danalbert Differential Revision: http://reviews.llvm.org/D12586 llvm-svn: 246749
* Have the Process hold a weak_ptr to the Target.Zachary Turner2015-09-012-19/+20
| | | | llvm-svn: 246578
OpenPOWER on IntegriCloud