summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/gdb-remote
Commit message (Collapse)AuthorAgeFilesLines
* Use absolute module path when possible if sent in svr4 packetsFrancis Ricci2016-04-271-8/+1
| | | | | | | | | | | | | | | | | | | | | Summary: If the remote uses svr4 packets to communicate library info, the LoadUnload tests will fail, as lldb only used the basename for modules, causing problems when two modules have the same basename. Using absolute path as sent by the remote will ensure that lldb locates the module from the correct directory when there are overlapping basenames. When debugging a remote process, LoadModuleAtAddress will still fall back to using basename and module_search_paths, so we don't need to worry about using absolute paths in this case. Reviewers: ADodds, jasonmolenda, clayborg, ovyalov Subscribers: lldb-commits, sas Differential Revision: http://reviews.llvm.org/D19557 llvm-svn: 267741
* Maintain register numbering across xml include featuresFrancis Ricci2016-04-251-6/+7
| | | | | | | | | | | | | | | | | | Summary: If the remote uses include features when communicating xml register info back to lldb, the existing code would reset the lldb register index at the beginning of each include node. This would lead to multiple registers having the same lldb register index. Since the lldb register numbers should be contiguous and unique, maintain them accross the parsing of all of the xml feature nodes. Reviewers: jingham, jasonmolenda, clayborg Subscribers: lldb-commits, sas Differential Revision: http://reviews.llvm.org/D19303 llvm-svn: 267468
* Properly unload modules from target image list when using svr4 packetsFrancis Ricci2016-04-251-2/+24
| | | | | | | | | | | | | | | | | | | Summary: When we receive an svr4 packet from the remote, we check for new modules and add them to the list of images in the target. However, we did not do the same for modules which have been removed. This was causing TestLoadUnload to fail when using ds2, which uses svr4 packets to communicate all library info on Linux. This patch fixes the failing test. Reviewers: zturner, tfiala, ADodds Subscribers: lldb-commits, sas Differential Revision: http://reviews.llvm.org/D19230 llvm-svn: 267467
* Use Process Plugin register indices when communicating with remoteFrancis Ricci2016-04-252-8/+9
| | | | | | | | | | | | | | | | | | Summary: eRegisterKindProcessPlugin is used to store the register indices used by the remote, and eRegisterKindLLDB is used to store the internal lldb register indices. However, we're currently using the lldb indices instead of the process plugin indices when sending p/P packets. This will break if the remote uses non-contiguous register indices. Reviewers: jasonmolenda, clayborg Subscribers: lldb-commits, sas Differential Revision: http://reviews.llvm.org/D19305 llvm-svn: 267466
* Reset continue_after_async only if neither SIGINIT nor SIGSTOP received.Oleksiy Vyalov2016-04-081-4/+5
| | | | | | http://reviews.llvm.org/D18886 llvm-svn: 265843
* In GDBRemoteCommunicationClient::GetHostInfo, don't set theJason Molenda2016-04-071-14/+0
| | | | | | | | | | | | | | | | | | os to "ios" or "macosx" if it is unspecified. For environments where there genuinely is no os, we don't want to errantly convert that to ios/macosx, e.g. bare board debugging. Change PlatformRemoteiOS, PlatformRemoteAppleWatch, and PlatformRemoteAppleTV to not create themselves if we have an unspecified OS. Same problem - these are not appropriate platforms for bare board debugging environments. Have Process::Attach's logging take place if either process or target logging is enabled. <rdar://problem/25592378> llvm-svn: 265732
* Revert "Reduce code duplication in ProcessGDBRemote"Pavel Labath2016-04-072-20/+39
| | | | | | | In turns out this does make a functional change, in case when the inferior hits an int3 that was not placed by the debugger. Backing out for now. llvm-svn: 265647
* Reduce code duplication in ProcessGDBRemotePavel Labath2016-04-062-39/+20
| | | | | | | | | | | | | | | | Summary: SetThreadStopInfo was checking for a breakpoint at the current PC several times. This merges the identical code into a separate function. I've left one breakpoint check alone, as it was doing more complicated stuff, and it did not see a way to merge that without making the interface complicated. NFC. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18819 llvm-svn: 265560
* Fix a cornercase in breakpoint reportingPavel Labath2016-04-061-0/+17
| | | | | | | | | | | | | | | | | | | | Summary: This resolves a similar problem as D16720 (which handled the case when we single-step onto a breakpoint), but this one deals with involutary stops: when we stop a thread (e.g. because another thread has hit a breakpont and we are doing a full stop), we can end up stopping it right before it executes a breakpoint instruction. In this case, the stop reason will be empty, but we will still step over the breakpoint when do the next resume, thereby missing a breakpoint hit. I have observed this happening in TestConcurrentEvents, but I have no idea how to reproduce this behavior more reliably. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18692 llvm-svn: 265525
* Allow gdbremote process to read modules from memoryStephane Sezer2016-04-052-19/+14
| | | | | | | | | | | | | | | | | | | | | | Summary: The logic to read modules from memory was added to LoadModuleAtAddress in the dynamic loader, but not in process gdb remote. This means that when the remote uses svr4 packets to give library info, libraries only present on the remote will not be loaded. This patch therefore involves some code duplication from LoadModuleAtAddress in the dynamic loader, but removing this would require some amount of code refactoring. Reviewers: ADodds, tberghammer, tfiala, deepak2427, ted Subscribers: tfiala, lldb-commits, sas Differential Revision: http://reviews.llvm.org/D18531 Change by Francis Ricci <fjricci@fb.com> llvm-svn: 265418
* Fixed an issue that could cause debugserver to return two stop reply packets ↵Greg Clayton2016-04-012-4/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ($T packets) for one \x03 interrupt. The problem was that when a \x03 byte is sent to debugserver while the process is running, and up calling: rnb_err_t RNBRemote::HandlePacket_stop_process (const char *p) { if (!DNBProcessInterrupt(m_ctx.ProcessID())) HandlePacket_last_signal (NULL); return rnb_success; } In the call to DNBProcessInterrupt we did: nub_bool_t DNBProcessInterrupt(nub_process_t pid) { MachProcessSP procSP; if (GetProcessSP (pid, procSP)) return procSP->Interrupt(); return false; } This would always return false. It would cause HandlePacket_stop_process to always call "HandlePacket_last_signal (NULL);" which would send an extra stop reply packet _if_ the process is stopped. On a machine with enough cores, it would call DNBProcessInterrupt(...) and then HandlePacket_last_signal(NULL) so quickly that it will never send out an extra stop reply packet. But if the machine is slow enough or doesn't have enough cores, it could cause the call to HandlePacket_last_signal() to actually succeed and send an extra stop reply packet. This would cause problems up in GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse() where it would get the first stop reply packet and then possibly return or execute an async packet. If it returned, then the next packet that was sent will get the second stop reply as its response. If it executes an async packet, the async packet will get the wrong response. To fix this I did the following: 1 - in debugserver, I fixed "bool MachProcess::Interrupt()" to return true if it sends the signal so we avoid sending the stop reply twice on slower machines 2 - Added a log line to RNBRemote::HandlePacket_stop_process() to say if we ever send an extra stop reply so we will see this in the darwin console output if this does happen 3 - Added response validators to StringExtractorGDBRemote so that we can verify some responses to some packets. 4 - Added validators to packets that often follow stop reply packets like the "m" packet for memory reads, JSON packets since "jThreadsInfo" is often sent immediately following a stop reply. 5 - Modified GDBRemoteCommunicationClient::SendPacketAndWaitForResponseNoLock() to validate responses. Any "StringExtractorGDBRemote &response" that contains a valid response verifier will verify the response and keep looking for correct responses up to 3 times. This will help us get back on track if we do get extra stop replies. If a StringExtractorGDBRemote does not have a response validator, it will accept any packet in response. 6 - In GDBRemoteCommunicationClient::SendPacketAndWaitForResponse we copy the response validator from the "response" argument over into m_async_response so that if we send the packet by interrupting the running process, we can validate the response we actually get in GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse() 7 - Modified GDBRemoteCommunicationClient::SendContinuePacketAndWaitForResponse() to always check for an extra stop reply packet for 100ms when the process is interrupted. We were already doing this because we might interrupt a process with a \x03 packet, yet the process was in the process of stopping due to another reason. This race condition could cause an extra stop reply packet because the GDB remote protocol says if a \x03 packet is sent while the process is stopped, we should send a stop reply packet back. Now we always check for an extra stop reply packet when we manually interrupt a process. The issue was showing up when our IDE would attempt to set a breakpoint while the process is running and this would happen: --> \x03 <-- $T<stop reply 1> --> z0,AAAAA,BB (set breakpoint) <-- $T<stop reply 1> (incorrect extra stop reply packet) --> c <-- OK (response from z0 packet) Now all packet traffic was off by one response. Since we now have a validator on the response for "z" packets, we do this: --> \x03 <-- $T<stop reply 1> --> z0,AAAAA,BB (set breakpoint) <-- $T<stop reply 1> (Ignore this because this can't be the response to z0 packets) <-- OK -- (we are back on track as this is a valid response to z0) ... As time goes on we should add more packet validators. <rdar://problem/22859505> llvm-svn: 265086
* Change over the broadcaster/listener process to hold shared or weak pointersJim Ingham2016-03-073-18/+18
| | | | | | | | | | | | | | to each other. This should remove some infrequent teardown crashes when the listener is not the debugger's listener. Processes now need to take a ListenerSP, not a Listener&. This required changing over the Process plugin class constructors to take a ListenerSP, instead of a Listener&. Other than that there should be no functional change. <rdar://problem/24580184> CrashTracer: [USER] Xcode at …ework: lldb_private::Listener::BroadcasterWillDestruct + 39 llvm-svn: 262863
* Fix all of the unannotated switch cases to annotate the fall through or do ↵Greg Clayton2016-02-261-27/+25
| | | | | | the right thing and break. llvm-svn: 261950
* Make sure code that is in the middle of figuring out the correct architectureJim Ingham2016-02-182-21/+32
| | | | | | | | | on attach uses the architecture it has figured out, rather than the Target's architecture, which may not have been updated to the correct value yet. <rdar://problem/24632895> llvm-svn: 261279
* Add -Wimplicit-fallthrough command line option to clang inJason Molenda2016-02-163-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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
OpenPOWER on IntegriCloud