summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/gdb-remote
Commit message (Collapse)AuthorAgeFilesLines
* 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
* Fix warnings detected by -Wpessimizing-movePavel Labath2015-07-281-6/+6
| | | | | | | | patch by Eugene Zelenko Differential Revision: http://reviews.llvm.org/D11429 llvm-svn: 243399
* [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
* Handle old style S packet correctlyBhushan D. Attarde2015-07-241-14/+13
| | | | | | | | | | | | | SUMMARY: This patch fixes couple of issues: 1. A thread tries to lock a mutex which is already locked. 2. Updating a thread list before the stop packet is parsed so that it can get a valid thread id and allows to set the stop info correctly. Reviewers: clayborg Subscribers: mohit.bhakkad, sagar, jaydeep, lldb-commits Differential Revision: http://reviews.llvm.org/D11449 llvm-svn: 243091
* Add UNUSED_IF_ASSERT_DISABLED and apply it.Bruce Mitchener2015-07-241-1/+1
| | | | | | | | | | | | | | | Summary: This replaces (void)x; usages where they x was subsequently involved in an assertion with this macro to make the intent more clear. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11451 llvm-svn: 243074
* 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
* Fix warnings.Bruce Mitchener2015-07-221-0/+1
| | | | | | | | | | Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11404 llvm-svn: 242913
* Fix warnings found by -Wextra-semiPavel Labath2015-07-221-1/+1
| | | | | | patch by Eugene Zelenko. llvm-svn: 242875
* Fix typos.Bruce Mitchener2015-07-222-4/+4
| | | | | | | | | | | | Summary: Fix a bunch of typos. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11386 llvm-svn: 242856
* [NativeProcessLinux] Integrate MainLoopPavel Labath2015-07-212-18/+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-212-66/+70
| | | | | | | | | | | | | | | | 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
* More packet performance improvements. Greg Clayton2015-07-172-148/+212
| | | | | | | | Changed the "jthreads" key/value in the stop reply packets to be "jstopinfo". This JSON only contains threads with valid stop reasons and allows us not to have to ask about other threads via qThreadStopInfo when we are stepping. The "jstopinfo" only gets sent if there are more than one thread since the stop reply packet contains all the info needed for a single thread. Added a Process::WillPublicStop() in case process subclasses want to do any extra gathering for public stops. For ProcessGDBRemote, we end up sending a jThreadsInfo packet to gather all expedited registers, expedited memory and MacOSX queue information. We only do this for public stops to minimize the packets we send when we have multiple private stops. Multiple private stops happen when a source level single step, step into or step out run the process multiple times while implementing the stepping, and none of these private stops make it out to the UI via notifications because they are private stops. llvm-svn: 242593
* [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-163-28/+174
| | | | | | | | | | | | | | | 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-162-2/+18
| | | | | | This seems to be causing major slowdows on the android buildbot. Reverting while I investigate. llvm-svn: 242391
* Added the ability to get JSON thread stop info with thread ID and stop info ↵Greg Clayton2015-07-151-0/+12
| | | | | | | | | | only in the normal stop reply packets using the new "jthreads" key value pair. This allows stepping operations that don't ever do a public stop to get all the info they need without having to send a jThreadsInfo packet since those tend to be large. This patch will be followed by a patch that will detect when we do a public stop, and when that happens we will send a jThreadsInfo packet at that time to get all expedited registers and memory. llvm-svn: 242352
* [NativeProcessLinux] Integrate MainLoopPavel Labath2015-07-152-18/+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
* Fix another little nit with detach and keep stopped, you have to checkJim Ingham2015-07-151-1/+2
| | | | | | both for packet success and that the response is OK. llvm-svn: 242262
* Correct length of packet that GDBRemoteCommunicationClient::Detach Jason Molenda2015-07-151-1/+1
| | | | | | | | should send when detaching and leaving the remote process/system halted. Previously only the 'D' initial char was sent, which resumed the process like a normal detach. llvm-svn: 242256
* Add comment explaning sanity check on packet size in the packet ↵Jason Molenda2015-07-141-0/+4
| | | | | | decompression method. llvm-svn: 242184
* Fix off-by-one error in the packet decompression routineJason Molenda2015-07-141-1/+1
| | | | | | | that would not pass through empty ("unsupported packet") replies correctly. llvm-svn: 242119
* Refactor Unix signals.Chaoren Lin2015-07-145-43/+44
| | | | | | | | | | | | | | | | | | Summary: - Consolidate Unix signals selection in UnixSignals. - Make Unix signals available from platform. - Add jSignalsInfo packet to retrieve Unix signals from remote platform. - Get a copy of the platform signal for each remote process. - Update SB API for signals. - Update signal utility in test suite. Reviewers: ovyalov, clayborg Subscribers: chaoren, jingham, labath, emaste, tberghammer, lldb-commits Differential Revision: http://reviews.llvm.org/D11094 llvm-svn: 242101
* Introduce a MainLoop class and switch llgs to use itPavel Labath2015-07-134-7/+71
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Add a another packet to the gdb-remote protocol,Jason Molenda2015-07-104-0/+65
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | jGetLoadedDynamicLibrariesInfos. This packet is similar to qXfer:libraries:read except that lldb supplies the number of solibs that should be reported about, and the start address for the list of them. At the initial process launch we'll read the full list of solibs linked by the process -- at this point we could be using qXfer:libraries:read -- but on subsequence solib-loaded notifications, we'll be fetching a smaller number of solibs, often only one or two. A typical Mac/iOS GUI app may have a couple hundred different solibs loaded - doing all of the loads via memory reads takes a couple of megabytes of traffic between lldb and debugserver. Having debugserver summarize the load addresses of all the solibs and sending it in JSON requires a couple of hundred kilobytes of traffic. It's a significant performance improvement when communicating over a slower channel. This patch leaves all of the logic for loading the libraries in DynamicLoaderMacOSXDYLD -- it only call over ot ProcesGDBRemote to get the JSON result. If the jGetLoadedDynamicLibrariesInfos packet is not implemented, the normal technique of using memory read packets to get all of the details from the target will be used. <rdar://problem/21007465> llvm-svn: 241964
* 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
* Implement qXfer:libraries:read.Stephane Sezer2015-07-081-59/+111
| | | | | | | | | | | | | | Summary: This is used on non-unix platforms, where qXfer:libraries-svr4:read doesn't make sense. Windows uses that for instance. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11036 llvm-svn: 241712
* 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
* Fix cmake build after recent JSON changesPavel Labath2015-07-071-1/+1
| | | | | | | I have moved StringExtractor.h into the include/ folder so that it can be properly included by everyone. llvm-svn: 241572
* Fix typosBruce Mitchener2015-07-021-1/+1
| | | | | | | | | | | | Summary: Fixes more typos. Reviewers: clayborg Subscribers: lldb-commits-list Differential Revision: http://reviews.llvm.org/D10898 llvm-svn: 241289
* Change search order of target definition files.Ewan Crawford2015-06-301-9/+13
| | | | | | | | | | | | Make the python target definition file have highest priority so that we can set the remote stub breakpoint pc offset using it. Reviewers: clayborg Subscribers: ted, deepak2427, lldb-commits Differential revision: http://reviews.llvm.org/D10775 llvm-svn: 241063
* More packet reduction when debugging with GDB server.Greg Clayton2015-06-294-62/+219
| | | | | | | | | - Avoid sending the qfThreadInfo, qsThreadInfo packets if we have a stop reply packet with the threads already (save 2 round trip packets) - Include the qname, qserial and qkind in the JSON info - Report the qname, qserial and qkind to the thread so it can cache it to avoid many packets on MacOSX and iOS - Don't clear all discoverable settings when we exec, just the ones we need to saves 1-5 packets for each exec. llvm-svn: 240988
* XML register info fixEwan Crawford2015-06-262-5/+5
| | | | | | | | | | | | | | | | | | There are a couple of bugs in the XML register info handling which this patch fixes: + conflicting variable names in lambda, both capture list and parameters contains a variable called 'name'. + prev_reg_num, which sets the register number, should be incremented after each register is processed. + Windows errors regarding empty strings and the 'xi:' prefix disappearing from 'xi:include' node name. Reviewers: clayborg Subscribers: lldb-commits, deepak2427 Differential Revision: http://reviews.llvm.org/D10731 llvm-svn: 240768
* Resubmitting 240466 after fixing the linux test suite failures.Greg Clayton2015-06-255-225/+520
| | | | | | | | | | | | | | | A few extras were fixed - Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were accessing the address of a symbol when the symbol's value wasn't an address symbol. On MacOSX, undefined symbols have a value zero and some places where using the symbol's address and getting an absolute address of zero (since an Address object with no section and an m_offset whose value isn't LLDB_INVALID_ADDRESS is considered an absolute address). So fixing this required some changes to make sure people were getting what they expected. - Since some places want to access the address as a reference, I added a few new functions to symbol: Address &Symbol::GetAddressRef(); const Address &Symbol::GetAddressRef() const; Linux test suite passes just fine now. <rdar://problem/21494354> llvm-svn: 240702
* Proper handling of QNonStop packet response.Ewan Crawford2015-06-241-1/+1
| | | | | | Turn non-stop mode off if reply to QNonStop packet isn't an OK. llvm-svn: 240546
* Implement the "qSymbol" packet in order to be able to read queue information ↵Greg Clayton2015-06-236-9/+194
| | | | | | | | | | | | | | in debugserver and return the info in the stop reply packets. A "qSymbol::" is sent when shared libraries have been loaded by hooking into the Process::ModulesDidLoad() function from within ProcessGDBRemote. This function was made virtual so that the ProcessGDBRemote version is called, which then first calls the Process::ModulesDidLoad(), and then it queries for any symbol lookups that the remote GDB server might want to do. This allows debugserver to request the "dispatch_queue_offsets" symbol so that it can read the queue name, queue kind and queue serial number and include this data as part of the stop reply packet. Previously each thread would have to do 3 memory reads in order to read the queue name. This is part of reducing the number of packets that are sent between LLDB and the remote GDB server. <rdar://problem/21494354> llvm-svn: 240466
* Add handling of async notify packetsEwan Crawford2015-06-234-53/+186
| | | | | | | | | | | | | | | | This patch adds a listener to the AynscThread in ProcessGDBRemote, specifically for dealing with any async notification packets. From the broadcast our listener receives we can process the notify packet from the event data. A handler function then sets the thread stop info from this packet, and updates lldb by setting the process private state to stopped. Allowing the async thread to go back to sleep and getting the main thread to handle the implications of a state change. When sending a vCont in nonstop mode we also get a different reply from all-stop mode, an OK response as opposed to a stop reply. So a condition is added to handle this and set the process state without the stop-reply data. Reviewers: clayborg Subscribers: lldb-commits, labath, ted, aidan.dodds, deepak2427 Differential Revision: http://reviews.llvm.org/D10544 llvm-svn: 240397
* Revert "Reduced packet counts to the remote GDB server where possible."Chaoren Lin2015-06-235-468/+207
| | | | | | | | | | This reverts commit 0cc0745ea9c68d7fdcadc9904cee3f13c96dae60. Due to breakage on Linux build bot: http://lab.llvm.org:8011/builders/lldb-x86_64-ubuntu-14.04-cmake/builds/3436 llvm-svn: 240371
* Reduced packet counts to the remote GDB server where possible.Greg Clayton2015-06-225-207/+468
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have been working on reducing the packet count that is sent between LLDB and the debugserver on MacOSX and iOS. Our approach to this was to reduce the packets required when debugging multiple threads. We currently make one qThreadStopInfoXXXX call (where XXXX is the thread ID in hex) per thread except the thread that stopped with a stop reply packet. In order to implement multiple thread infos in a single reply, we need to use structured data, which means JSON. The new jThreadsInfo packet will attempt to retrieve all thread infos in a single packet. The data is very similar to the stop reply packets, but packaged in JSON and uses JSON arrays where applicable. The JSON output looks like: [ { "tid":1580681, "metype":6, "medata":[2,0], "reason":"exception", "qaddr":140735118423168, "registers": { "0":"8000000000000000", "1":"0000000000000000", "2":"20fabf5fff7f0000", "3":"e8f8bf5fff7f0000", "4":"0100000000000000", "5":"d8f8bf5fff7f0000", "6":"b0f8bf5fff7f0000", "7":"20f4bf5fff7f0000", "8":"8000000000000000", "9":"61a8db78a61500db", "10":"3200000000000000", "11":"4602000000000000", "12":"0000000000000000", "13":"0000000000000000", "14":"0000000000000000", "15":"0000000000000000", "16":"960b000001000000", "17":"0202000000000000", "18":"2b00000000000000", "19":"0000000000000000", "20":"0000000000000000"}, "memory":[ {"address":140734799804592,"bytes":"c8f8bf5fff7f0000c9a59e8cff7f0000"}, {"address":140734799804616,"bytes":"00000000000000000100000000000000"} ] } ] It contains an array of dicitionaries with all of the key value pairs that are normally in the stop reply packet. Including the expedited registers. Notice that is also contains expedited memory in the "memory" key. Any values in this memory will get included in a new L1 cache in lldb_private::Process where if a memory read request is made and that memory request fits into one of the L1 memory cache blocks, it will use that memory data. If a memory request fails in the L1 cache, it will fall back to the L2 cache which is the same block sized caching we were using before these changes. This allows a process to expedite memory that you are likely to use and it reduces packet count. On MacOSX with debugserver, we expedite the frame pointer backchain for a thread (up to 256 entries) by reading 2 pointers worth of bytes at the frame pointer (for the previous FP and PC), and follow the backchain. Most backtraces on MacOSX and iOS now don't require us to read any memory! We will try these packets out and if successful, we should port these to lldb-server in the near future. <rdar://problem/21494354> llvm-svn: 240354
* Add a new wart, I mean feature, on to gdb-remote protocol: compression.Jason Molenda2015-06-184-5/+437
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For some communication channels, sending large packets can be very slow. In those cases, it may be faster to compress the contents of the packet on the target device and decompress it on the debug host system. For instance, communicating with a device using something like Bluetooth may be an environment where this tradeoff is a good one. This patch adds a new field to the response to the "qSupported" packet (which returns a "qXfer:features:" response) -- SupportedCompressions and DefaultCompressionMinSize. These tell you what the remote stub can support. lldb, if it wants to enable compression and can handle one of those algorithms, it can send a QEnableCompression packet specifying the algorithm and optionally the minimum packet size to use compression on. lldb may have better knowledge about the best tradeoff for a given communication channel. I added support to debugserver an lldb to use the zlib APIs (if -DHAVE_LIBZ=1 is in CFLAGS and -lz is in LDFLAGS) and the libcompression APIs on Mac OS X 10.11 and later (if -DHAVE_LIBCOMPRESSION=1). libz "zlib-deflate" compression. libcompression can support deflate, lz4, lzma, and a proprietary lzfse algorithm. libcompression has been hand-tuned for Apple hardware so it should be preferred if available. debugserver currently only adds the SupportedCompressions when it is being run on an Apple watch (TARGET_OS_WATCH). Comment that #if out from RNBRemote.cpp if you want to enable it to see how it works. I haven't tested this on a native system configuration but surely it will be slower to compress & decompress the packets in a same-system debug session. I haven't had a chance to add support for this to GDBRemoteCommunciationServer.cpp yet. <rdar://problem/21090180> llvm-svn: 240066
* Fetch object file load address if it isn't specified by the linkerTamas Berghammer2015-06-184-2/+80
| | | | | | Differential revision: http://reviews.llvm.org/D10490 llvm-svn: 240052
* [LLDB][MIPS] Hardware Watchpoints for MIPSMohit K. Bhakkad2015-06-181-1/+5
| | | | | | | | Reviewers: clayborg, jingham. Subscribers: jaydeep, bhushan, dsanders, sagar, lldb-commits. Differential Revision: http://reviews.llvm.org/D9142 llvm-svn: 239991
* Add Read Thread to GDBRemoteCommunicationEwan Crawford2015-06-164-8/+167
| | | | | | | | | | | | | | | | In order to support asynchronous notifications for non-stop mode this patch adds a packet read thread. This is done by implementing AppendBytesToCache() from the communications class, which continually reads packets into a packet queue. To initialize this thread StartReadThread() must be called by the client, so since llgs and platform tools use the GBDRemoteCommunicatos code they must also call this function as well as ProcessGDBRemote. When the read thread detects an async notify packet it broadcasts this event, where the matching listener will be added in the next non-stop patch. Packets are now accessed by calling ReadPacket() which pops a packet from the queue, instead of using WaitForPacketWithTimeoutMicroSecondsNoLock() Reviewers: vharron, clayborg Subscribers: lldb-commits, labath, ted, domipheus, deepak2427 Differential Revision: http://reviews.llvm.org/D10085 llvm-svn: 239824
OpenPOWER on IntegriCloud