summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/gdb-remote
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* Make ProcessGDBRemote get a //copy// of platform Unix signals.Chaoren Lin2015-09-012-0/+9
| | | | | | | | | | | | Summary: Update to http://reviews.llvm.org/rL243618. Reviewers: jaydeep, clayborg Subscribers: labath, tberghammer, lldb-commits Differential Revision: http://reviews.llvm.org/D12420 llvm-svn: 246557
* A few small comment fixups with terminology "gcc" -> "eh_frame", "gdb" -> ↵Jason Molenda2015-09-011-6/+6
| | | | | | | | "stabs". Just noticed these while reading through some code. llvm-svn: 246530
* In SendContinuePacketAndWaitForResponse there is a special bit ofJason Molenda2015-08-261-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | code that looks for a second stop-reply packet in response to an interrupt (control-c). This is to handle the case where where a stop packet is making its way up to lldb right as lldb decides to interrupt the inferior. If the inferior is running and we interrupt it, we'd expect a T11 type response meaning that the inferior halted because of the interrupt. But if the interrupt gets a T05 type response instead, meaning that we stopped execution by hitting a breakpoint or whatever, then the interrupt was received while the inferior was already paused and so it is treated as a "?" packet -- the remote stub will send the stop message a second time. There's a timeout where we wait to get this second stop reply packet in SendContinuePacketAndWaitForResponse, currently 1ms. For a slow remote target, it may take longer than that to send the second stop reply packet. If that happens, then lldb will use that second stop reply packet as the response for the next packet request it makes to the remote stub. The two will be out of sync by one packet for the rest of the debug session and it's going to go badly from then on. I've seen times as slow as 46ms, and given the severity of missing that second stop reply packet, I'm increasing the timeout to 100ms, or 0.1sec. <rdar://problem/21990791> llvm-svn: 246004
* Adds support for hardware watchpoints on Arm targets.Omair Javaid2015-08-251-0/+2
| | | | | | | | | | | | | | http://reviews.llvm.org/D9703 This updated patches correct problems in arm hardware watchpoint support patch posted earlier. This patch has been tested on samsung chromebook (ARM - Linux) and PandaBoard using basic watchpoint test application. Also it was tested on Nexus 7 Android device. On chromebook linux we are able to set and clear all types of watchpoints but on android we end up getting a watchpoint packet error because we are not able to call hardware watchpoint ptrace functions successfully. llvm-svn: 245961
* Implement handling of `library:` keys in thread stop replies.Stephane Sezer2015-08-211-0/+4
| | | | | | | | | | | | | | | | | | | | Summary: When a windows remote stops because of a DLL load/unload, the debug server sends a stop reply packet that contains a `library` key with any value (usually just `library:1`). This indicates to the debugger that a library has been loaded or unloaded and that the list of libraries should be refreshed (usually with `qXfer:libraries:read`). This change just triggers a call to `LoadModules()` which in turns will send a remote library read command when a stop reply that requests it is received. Reviewers: clayborg, zturner, tberghammer Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12218 llvm-svn: 245708
* The llvm Triple for an armv6m now comes back as llvm::Triple::thumb.Jason Molenda2015-08-212-4/+6
| | | | | | | | | | | | | | This was breaking disassembly for arm machines that we force to be thumb mode all the time because we were only checking for llvm::Triple::arm. i.e. armv6m (ARM Cortex-M0) armv7m (ARM Cortex-M3) armv7em (ARM Cortex-M4) <rdar://problem/22334522> llvm-svn: 245645
* Understand absolute base addresses in ProcessGDBRemote::GetLoadedModuleList.Stephane Sezer2015-08-202-8/+28
| | | | | | | | | | | | | | | | Summary: This is useful when dealing with Windows remote that use only the qXfer:libraries command which returns absolute base addresses, as opposed to qXfer:libraries-svr4 which returns relative offsets for module bases. Reviewers: clayborg, zturner, ADodds Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12204 llvm-svn: 245625
* Fix some format strings in ProcessGDBRemote.cpp.Stephane Sezer2015-08-201-2/+2
| | | | | | | | | | | | Summary: Size specifier should come after `%` not before. Reviewers: clayborg, ADodds Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12203 llvm-svn: 245608
* If the filename specified by plugin.process.gdb-remote.target-definition-file,Jason Molenda2015-08-201-0/+5
| | | | | | doesn't exist, see if it needs tilde expansion before we ignore it completely. llvm-svn: 245537
* When the target definition is unparseable, print an error messageJason Molenda2015-08-201-0/+7
| | | | | | | | | to the user. e.g. specified via the plugin.process.gdb-remote.target-definition-file setting. Currently we silently ignore the target definition if there is a parse error. llvm-svn: 245536
* Fix AArch64 watchpoint exception handlingOmair Javaid2015-08-181-1/+3
| | | | | | http://reviews.llvm.org/D11987 llvm-svn: 245273
* A messy bit of cleanup: Move towards more descriptive namesJason Molenda2015-08-153-9/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [LLDB][MIPS] Use qfThreadID if qC packet is not supported by targetJaydeep Patil2015-08-131-0/+15
| | | | | | | | | | | SUMMARY: The patch uses qfThreadID to get the thread IDs if qC packet is not supported by target. Reviewers: jingham, clayborg Subscribers: nitesh.jain, mohit.bhakkad, sagar, bhushan and lldb-commits Differential Revision: http://reviews.llvm.org/D11519 llvm-svn: 244866
* [LLDB][MIPS] Support standard GDB remote stop reply packet for watchpointJaydeep Patil2015-08-133-7/+41
| | | | | | | | | | | | SUMMARY: The patch supports TAAwatch:addr packet. The patch also sets m_watchpoints_trigger_after_instruction to eLazyBoolNo when qHostInfo or qWatchpointSupportInfo is not supported by the target. Reviewers: jingham, clayborg Subscribers: nitesh.jain, mohit.bhakkad, sagar, bhushan and lldb-commits Differential Revision: http://reviews.llvm.org/D11747 llvm-svn: 244865
* [LLDB][MIPS] Handle false positives for MIPS hardware watchpointsJaydeep Patil2015-08-131-1/+2
| | | | | | | | | | | | | | | | SUMMARY: Last 3bits of the watchpoint address are masked by the kernel. For example, n is at 0x120010d00 and m is 0x120010d04. When a watchpoint is set at m, then watch exception is generated even when n is read/written. To handle this case, instruction at PC is emulated to find the base address of the load/store instruction. This address is then appended to the description of the stop-info packet. Client then reads this information to check whether the user has set a watchpoint on this address. Reviewers: jingham, clayborg Subscribers: nitesh.jain, mohit.bhakkad, sagar, bhushan and lldb-commits Differential Revision: http://reviews.llvm.org/D11672 llvm-svn: 244864
* Fix LLGS to enable read type watchpointsOmair Javaid2015-08-121-5/+4
| | | | | | http://reviews.llvm.org/D11902 llvm-svn: 244741
* Fix a infinite loop when killing a process that is in the middle of loading ↵Greg Clayton2015-08-111-79/+76
| | | | | | | | | | shared libraries. The issue was we were sending a "qSymbol::" packet and it we were already disconnected were weren't exiting the while loop if we didn't successfully send the qSymbol packet. <rdar://problem/22098746> llvm-svn: 244683
* GDBRemoteCommunication::DecompressPacket assumed that the buffer it wasJason Molenda2015-08-021-11/+20
| | | | | | | | | | working with (the Communication m_bytes ivar) contained a single packet. Instead, it may contain multitudes. Find the boundaries of the first packet in the buffer and replace that with the decompressed version leaving the rest of the buffer unmodified. <rdar://problem/21841377> llvm-svn: 243846
* Convert the ScriptInterpreter system to a plugin-based one.Zachary Turner2015-07-301-3/+0
| | | | | | | | | | | | | | | | | | | | | | | Previously embedded interpreters were handled as ad-hoc source files compiled into source/Interpreter. This made it hard to disable a specific interpreter, or to add support for other interpreters and allow the developer to choose which interpreter(s) were enabled for a particular build. This patch converts script interpreters over to a plugin-based system. Script interpreters now live in source/Plugins/ScriptInterpreter, and the canonical LLDB interpreter, ScriptInterpreterPython, is moved there as well. Any new code interfacing with the Python C API must live in this location from here on out. Additionally, generic code should never need to reference or make assumptions about the presence of a specific interpreter going forward. Differential Revision: http://reviews.llvm.org/D11431 Reviewed By: Greg Clayton llvm-svn: 243681
* Use only unnamed pipes to launch lldb-server gdbserver.Chaoren Lin2015-07-301-19/+21
| | | | | | | | | | | | | | | | | Summary: If we used unnamed pipes instead of named pipes, we can avoid having the file system littered with debugserver-named-pipes if lldb-server happens to crash for whatever reason. Also, on some buggy systems, it's possible to be able to create but not to delete a fifo. Ideally, support for unnamed pipes should be added to debugserver as well, so we can avoid the `#ifdef` here. Reviewers: clayborg, vharron, chying Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11609 llvm-svn: 243667
* [LLDB][MIPS] Create Unix Signals based on target architectureJaydeep Patil2015-07-301-1/+7
| | | | | | | | | | | SUMMARY: The patch creates Unix Signals based on target architecture. For MIPS it creates MipsLinuxSignals. Reviewers: clayborg Subscribers: mohit.bhakkad, sagar, lldb-commits Differential Revision: http://reviews.llvm.org/D11455 llvm-svn: 243618
* [LLGS] Spawned process handling cleanupPavel Labath2015-07-296-202/+127
| | | | | | | | | | | | | | | | | | | 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
* When debugserver fails to attach to a process on a DarwinJason Molenda2015-07-291-2/+22
| | | | | | | | | | | | | | | | | | | system, make a couple of additional checks to see if the attach was denied via the System Integrity Protection that is new in Mac OS X 10.11. If so, return a special E87 error code to indicate this to lldb. Up in lldb, if we receive the E87 error code, be specific about why the attach failed. Also detect the more common case of general attach failure and print a better error message than "lost connection". I believe this code will all build on Mac OS X 10.10 systems. It may not compile or run on earlier versions of the OS. None of this should build on other non-darwin systems. llvm-svn: 243511
OpenPOWER on IntegriCloud