summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Allow LLDB.framework to locate debugserver even when it doesn't exist in the ↵Greg Clayton2015-10-191-0/+1
| | | | | | | | | | 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
* 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-141-8/+2
| | | | | | | | | | | | | | | | | 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][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
* 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
* Clean up register naming conventions inside lldb. Jason Molenda2015-09-151-10/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "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
* Fix deadlock while attaching to inferiorsPavel Labath2015-09-031-148/+158
| | | | | | | | | | | | | | | | | | | | 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
* Have the Process hold a weak_ptr to the Target.Zachary Turner2015-09-011-16/+17
| | | | llvm-svn: 246578
* Make ProcessGDBRemote get a //copy// of platform Unix signals.Chaoren Lin2015-09-011-0/+6
| | | | | | | | | | | | 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
* 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-211-4/+5
| | | | | | | | | | | | | | 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-201-7/+27
| | | | | | | | | | | | | | | | 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
* A messy bit of cleanup: Move towards more descriptive namesJason Molenda2015-08-151-5/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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] Support standard GDB remote stop reply packet for watchpointJaydeep Patil2015-08-131-1/+16
| | | | | | | | | | | | 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
* [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
* 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
* 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
* Fix warnings found by -Wextra-semiPavel Labath2015-07-221-1/+1
| | | | | | patch by Eugene Zelenko. llvm-svn: 242875
* More packet performance improvements. Greg Clayton2015-07-171-146/+203
| | | | | | | | 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
* Add jThreadsInfo support to lldb-serverPavel Labath2015-07-161-0/+4
| | | | | | | | | | | | | | | 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
* 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
* Refactor Unix signals.Chaoren Lin2015-07-141-39/+4
| | | | | | | | | | | | | | | | | | 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
* Add a another packet to the gdb-remote protocol,Jason Molenda2015-07-101-0/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* 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
* 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-291-8/+154
| | | | | | | | | - 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-261-3/+3
| | | | | | | | | | | | | | | | | | 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-251-214/+422
| | | | | | | | | | | | | | | 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-231-0/+45
| | | | | | | | | | | | | | 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-231-53/+127
| | | | | | | | | | | | | | | | 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-231-417/+200
| | | | | | | | | | 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-221-200/+417
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fetch object file load address if it isn't specified by the linkerTamas Berghammer2015-06-181-0/+41
| | | | | | Differential revision: http://reviews.llvm.org/D10490 llvm-svn: 240052
* Add Read Thread to GDBRemoteCommunicationEwan Crawford2015-06-161-0/+6
| | | | | | | | | | | | | | | | 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
* Refactor many file functions to use FileSpec over strings.Chaoren Lin2015-05-291-42/+41
| | | | | | | | | | | | | | | | | Summary: This should solve the issue of sending denormalized paths over gdb-remote if we stick to GetPath(false) in GDBRemoteCommunicationClient, and let the server handle any denormalization. Reviewers: ovyalov, zturner, vharron, clayborg Reviewed By: clayborg Subscribers: tberghammer, emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D9728 llvm-svn: 238604
* Don't #include "lldb-python.h" from anywhere.Zachary Turner2015-05-291-1/+0
| | | | | | | | | | | | | Since interaction with the python interpreter is moving towards being more isolated, we won't be able to include this header from normal files anymore, all includes of it should be localized to the python library which will live under source/bindings/API/Python after a future patch. None of the files that were including this header actually depended on it anyway, so it was just a dead include in every single instance. llvm-svn: 238581
* Report inferior SIGSEGV as a signal instead of an exception on linuxPavel Labath2015-05-291-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, we reported inferior receiving SIGSEGV (or SIGILL, SIGFPE, SIGBUS) as an "exception" to LLDB, presumably to match OSX behaviour. Beside the fact that we were basically lying to the user, this was also causing problems with inferiors which handle SIGSEGV by themselves, since LLDB was unable to reinject this signal back into the inferior. This commit changes LLGS to report SIGSEGV as a signal. This has necessitated some changes in the test-suite, which had previously used eStopReasonException to locate threads that crashed. Now it uses platform-specific logic, which in the case of linux searches for eStopReasonSignaled with signal=SIGSEGV. I have also added the ability to set the description of StopInfoUnixSignal using the description field of the gdb-remote packet. The linux stub uses this to display additional information about the segfault (invalid address, address access protected, etc.). Test Plan: All tests pass on linux and osx. Reviewers: ovyalov, clayborg, emaste Subscribers: emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D10057 llvm-svn: 238549
* Add a new "qEcho" packet with the following format:Greg Clayton2015-05-291-0/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | qEcho:%s where '%s' is any valid string. The response to this packet is the exact packet itself with no changes, just reply with what you received! This will help us to recover from packets timing out much more gracefully. Currently if a packet times out, LLDB quickly will hose up the debug session. For example, if we send a "abc" packet and we expect "ABC" back in response, but the "abc" command takes longer than the current timeout value this will happen: --> "abc" <-- <<<error: timeout>>> Now we want to send "def" and get "DEF" back: --> "def" <-- "ABC" We got the wrong response for the "def" packet because we didn't sync up with the server to clear any current responses from previously issues commands. The fix is to modify GDBRemoteCommunication::WaitForPacketWithTimeoutMicroSecondsNoLock() so that when it gets a timeout, it syncs itself up with the client by sending a "qEcho:%u" where %u is an increasing integer, one for each time we timeout. We then wait for 3 timeout periods to sync back up. So the above "abc" session would look like: --> "abc" <-- <<<error: timeout>>> 1 second --> "qEcho:1" <-- <<<error: timeout>>> 1 second <-- <<<error: timeout>>> 1 second <-- "abc" <-- "qEcho:1" The first timeout is from trying to get the response, then we know we timed out and we send the "qEcho:1" packet and wait for 3 timeout periods to get back in sync knowing that we might actually get the response for the "abc" packet in the mean time... In this case we would actually succeed in getting the response for "abc". But lets say the remote GDB server is deadlocked and will never response, it would look like: --> "abc" <-- <<<error: timeout>>> 1 second --> "qEcho:1" <-- <<<error: timeout>>> 1 second <-- <<<error: timeout>>> 1 second <-- <<<error: timeout>>> 1 second We then disconnect and say we lost connection. We might also have a bad GDB server that just dropped the "abc" packet on the floor. We can still recover in this case and it would look like: --> "abc" <-- <<<error: timeout>>> 1 second --> "qEcho:1" <-- "qEcho:1" Then we know our remote GDB server is still alive and well, and it just dropped the "abc" response on the floor and we can continue to debug. <rdar://problem/21082939> llvm-svn: 238530
* Change ProcessGDBRemote last stop packet to a container.Ewan Crawford2015-05-271-9/+37
| | | | | | | | | | | | | | | In ProcessGDBRemote we currently have a single packet, m_last_stop_packet, used to set the thread stop info. However in non-stop mode we can receive several stop reply packets in a sequence for different threads. As a result we need to use a container to hold them before they are processed. This patch also changes the return type of CheckPacket() so we can detect async notification packets. Reviewers: clayborg Subscribers: labath, ted, deepak2427, lldb-commits Differential Revision: http://reviews.llvm.org/D9853 llvm-svn: 238323
* Added XML to the host layer.Greg Clayton2015-05-261-560/+335
| | | | | | | | | | | | We know have on API we should use for all XML within LLDB in XML.h. This API will be easy back the XML parsing by different libraries in case libxml2 doesn't work on all platforms. It also allows the only place for #ifdef ...XML... to be in XML.h and XML.cpp. The API is designed so it will still compile with or without XML support and there is a static function "bool XMLDocument::XMLEnabled()" that can be called to see if XML is currently supported. All APIs will return errors, false, or nothing when XML isn't enabled. Converted all locations that used XML over to using the host XML implementation. Added target.xml support to debugserver. Extended the XML register format to work for LLDB by including extra attributes and elements where needed. This allows the target.xml to replace the qRegisterInfo packets and allows us to fetch all register info in a single packet. <rdar://problem/21090173> llvm-svn: 238224
* Did some cleanup to stop us from leaking Pipe file descriptors.Greg Clayton2015-05-231-4/+3
| | | | | | | | | | The main issue was the Communication::Disconnect() was calling its Connection::Disconnect() but this wouldn't release the pipes that the ConnectionFileDescriptor was using. We also have someone that is holding a strong reference to the Process so that when you re-run, target replaces its m_process_sp, but it doesn't get destructed because someone has a strong reference to it. I need to track that down. But, even if we have a strong reference to the a process that is outstanding, we need to call Process::Finalize() to have it release as much of its resources as possible to avoid memory bloat. Removed the ProcessGDBRemote::SetExitStatus() override and replaced it with ProcessGDBRemote::DidExit(). Now we aren't leaking file descriptors and the stand alone test suite should run much better. llvm-svn: 238089
* Added a new command in ProcessGDBRemote that can figure out the performance ↵Greg Clayton2015-05-211-0/+78
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | characterisitics of your GDB remote server. To addess this, attach to any GDB server and when stopped type: (lldb) process plugin packet speed-test The default will send a variety of packets with different amounts of data to send/receive and print the performance of each packet type: Testing sending 1000 packets of various sizes: qSpeedTest(send=0 , recv=0 ) in 0.057837000 sec for 17289.97 packets/sec ( 0.057837 ms per packet) with standard deviation of 0.007705 ms qSpeedTest(send=0 , recv=4 ) in 0.056162000 sec for 17805.63 packets/sec ( 0.056162 ms per packet) with standard deviation of 0.004439 ms qSpeedTest(send=0 , recv=8 ) in 0.057687000 sec for 17334.93 packets/sec ( 0.057687 ms per packet) with standard deviation of 0.008135 ms qSpeedTest(send=0 , recv=16 ) in 0.058547000 sec for 17080.29 packets/sec ( 0.058547 ms per packet) with standard deviation of 0.005884 ms qSpeedTest(send=0 , recv=32 ) in 0.058289000 sec for 17155.89 packets/sec ( 0.058289 ms per packet) with standard deviation of 0.004057 ms qSpeedTest(send=0 , recv=64 ) in 0.061324000 sec for 16306.83 packets/sec ( 0.061324 ms per packet) with standard deviation of 0.010838 ms qSpeedTest(send=0 , recv=128 ) in 0.065688000 sec for 15223.48 packets/sec ( 0.065688 ms per packet) with standard deviation of 0.006997 ms qSpeedTest(send=0 , recv=256 ) in 0.070621000 sec for 14160.09 packets/sec ( 0.070621 ms per packet) with standard deviation of 0.006188 ms qSpeedTest(send=0 , recv=512 ) in 0.086738000 sec for 11528.97 packets/sec ( 0.086738 ms per packet) with standard deviation of 0.007867 ms qSpeedTest(send=0 , recv=1024 ) in 0.146375000 sec for 6831.77 packets/sec ( 0.146375 ms per packet) with standard deviation of 0.010313 ms qSpeedTest(send=4 , recv=0 ) in 0.057807000 sec for 17298.94 packets/sec ( 0.057807 ms per packet) with standard deviation of 0.009702 ms .... It will then also use various sizes to receive 4MB of data from the GDB server and print out the stats: Testing receiving 4.0MB of data using varying receive packet sizes: qSpeedTest(send=0 , recv=32 ) 131072 packets needed to receive 4.0MB in 7.721290000 sec for 0.518048 MB/sec for 16975.40 packets/sec ( 0.058909 ms per packet) qSpeedTest(send=0 , recv=64 ) 65536 packets needed to receive 4.0MB in 4.029236000 sec for 0.992744 MB/sec for 16265.12 packets/sec ( 0.061481 ms per packet) qSpeedTest(send=0 , recv=128 ) 32768 packets needed to receive 4.0MB in 2.233854000 sec for 1.790627 MB/sec for 14668.82 packets/sec ( 0.068172 ms per packet) qSpeedTest(send=0 , recv=256 ) 16384 packets needed to receive 4.0MB in 1.160024000 sec for 3.448204 MB/sec for 14123.84 packets/sec ( 0.070802 ms per packet) qSpeedTest(send=0 , recv=512 ) 8192 packets needed to receive 4.0MB in 0.701603000 sec for 5.701230 MB/sec for 11676.12 packets/sec ( 0.085645 ms per packet) qSpeedTest(send=0 , recv=1024 ) 4096 packets needed to receive 4.0MB in 0.596786000 sec for 6.702570 MB/sec for 6863.43 packets/sec ( 0.145700 ms per packet) There is a JSON mode so we can use this in the test suite to track GDB server performance for each platform: (lldb) process plugin packet speed-test --json { "packet_speeds" : { "num_packets" : 1000, "results" : [ {"send_size" : 0, "recv_size" : 0, "total_time_nsec" : 64516000, "standard_deviation_nsec" : 20566 }, {"send_size" : 0, "recv_size" : 4, "total_time_nsec" : 59648000, "standard_deviation_nsec" : 10493 }, {"send_size" : 0, "recv_size" : 8, "total_time_nsec" : 56894000, "standard_deviation_nsec" : 5480 }, {"send_size" : 0, "recv_size" : 16, "total_time_nsec" : 59422000, "standard_deviation_nsec" : 6557 }, {"send_size" : 0, "recv_size" : 32, "total_time_nsec" : 61159000, "standard_deviation_nsec" : 12384 }, {"send_size" : 0, "recv_size" : 64, "total_time_nsec" : 61386000, "standard_deviation_nsec" : 9208 }, {"send_size" : 0, "recv_size" : 128, "total_time_nsec" : 64768000, "standard_deviation_nsec" : 4737 }, {"send_size" : 0, "recv_size" : 256, "total_time_nsec" : 71046000, "standard_deviation_nsec" : 5904 }, {"send_size" : 0, "recv_size" : 512, "total_time_nsec" : 87233000, "standard_deviation_nsec" : 8967 }, {"send_size" : 0, "recv_size" : 1024, "total_time_nsec" : 146629000, "standard_deviation_nsec" : 9526 }, {"send_size" : 4, "recv_size" : 0, "total_time_nsec" : 57131000, "standard_deviation_nsec" : 7884 }, {"send_size" : 4, "recv_size" : 4, "total_time_nsec" : 56772000, "standard_deviation_nsec" : 6064 }, {"send_size" : 4, "recv_size" : 8, "total_time_nsec" : 57450000, "standard_deviation_nsec" : 6341 }, {"send_size" : 4, "recv_size" : 16, "total_time_nsec" : 58279000, "standard_deviation_nsec" : 5998 }, {"send_size" : 4, "recv_size" : 32, "total_time_nsec" : 59995000, "standard_deviation_nsec" : 6294 }, {"send_size" : 4, "recv_size" : 64, "total_time_nsec" : 61632000, "standard_deviation_nsec" : 7838 }, {"send_size" : 4, "recv_size" : 128, "total_time_nsec" : 66535000, "standard_deviation_nsec" : 8026 }, {"send_size" : 4, "recv_size" : 256, "total_time_nsec" : 72754000, "standard_deviation_nsec" : 9519 }, {"send_size" : 4, "recv_size" : 512, "total_time_nsec" : 87072000, "standard_deviation_nsec" : 9268 }, {"send_size" : 4, "recv_size" : 1024, "total_time_nsec" : 147221000, "standard_deviation_nsec" : 9702 }, {"send_size" : 8, "recv_size" : 0, "total_time_nsec" : 57900000, "standard_deviation_nsec" : 7356 }, {"send_size" : 8, "recv_size" : 4, "total_time_nsec" : 58116000, "standard_deviation_nsec" : 7630 }, {"send_size" : 8, "recv_size" : 8, "total_time_nsec" : 57745000, "standard_deviation_nsec" : 8541 }, {"send_size" : 8, "recv_size" : 16, "total_time_nsec" : 59091000, "standard_deviation_nsec" : 7851 }, {"send_size" : 8, "recv_size" : 32, "total_time_nsec" : 59943000, "standard_deviation_nsec" : 6761 }, {"send_size" : 8, "recv_size" : 64, "total_time_nsec" : 62097000, "standard_deviation_nsec" : 8580 }, {"send_size" : 8, "recv_size" : 128, "total_time_nsec" : 69942000, "standard_deviation_nsec" : 16645 }, {"send_size" : 8, "recv_size" : 256, "total_time_nsec" : 72927000, "standard_deviation_nsec" : 11031 }, {"send_size" : 8, "recv_size" : 512, "total_time_nsec" : 87221000, "standard_deviation_nsec" : 8002 }, {"send_size" : 8, "recv_size" : 1024, "total_time_nsec" : 148696000, "standard_deviation_nsec" : 10383 }, {"send_size" : 16, "recv_size" : 0, "total_time_nsec" : 59890000, "standard_deviation_nsec" : 15160 }, {"send_size" : 16, "recv_size" : 4, "total_time_nsec" : 56664000, "standard_deviation_nsec" : 4650 }, {"send_size" : 16, "recv_size" : 8, "total_time_nsec" : 57574000, "standard_deviation_nsec" : 7787 }, {"send_size" : 16, "recv_size" : 16, "total_time_nsec" : 59312000, "standard_deviation_nsec" : 8104 }, {"send_size" : 16, "recv_size" : 32, "total_time_nsec" : 59764000, "standard_deviation_nsec" : 7496 }, {"send_size" : 16, "recv_size" : 64, "total_time_nsec" : 61644000, "standard_deviation_nsec" : 8331 }, {"send_size" : 16, "recv_size" : 128, "total_time_nsec" : 66476000, "standard_deviation_nsec" : 9251 }, {"send_size" : 16, "recv_size" : 256, "total_time_nsec" : 72386000, "standard_deviation_nsec" : 8627 }, {"send_size" : 16, "recv_size" : 512, "total_time_nsec" : 87810000, "standard_deviation_nsec" : 12318 }, {"send_size" : 16, "recv_size" : 1024, "total_time_nsec" : 146918000, "standard_deviation_nsec" : 11595 }, {"send_size" : 32, "recv_size" : 0, "total_time_nsec" : 56493000, "standard_deviation_nsec" : 6577 }, {"send_size" : 32, "recv_size" : 4, "total_time_nsec" : 57069000, "standard_deviation_nsec" : 5931 }, {"send_size" : 32, "recv_size" : 8, "total_time_nsec" : 57563000, "standard_deviation_nsec" : 8157 }, {"send_size" : 32, "recv_size" : 16, "total_time_nsec" : 59694000, "standard_deviation_nsec" : 6932 }, {"send_size" : 32, "recv_size" : 32, "total_time_nsec" : 60852000, "standard_deviation_nsec" : 8010 }, {"send_size" : 32, "recv_size" : 64, "total_time_nsec" : 61926000, "standard_deviation_nsec" : 8372 }, {"send_size" : 32, "recv_size" : 128, "total_time_nsec" : 66734000, "standard_deviation_nsec" : 8047 }, {"send_size" : 32, "recv_size" : 256, "total_time_nsec" : 72000000, "standard_deviation_nsec" : 8103 }, {"send_size" : 32, "recv_size" : 512, "total_time_nsec" : 88268000, "standard_deviation_nsec" : 12289 }, {"send_size" : 32, "recv_size" : 1024, "total_time_nsec" : 147946000, "standard_deviation_nsec" : 12122 }, {"send_size" : 64, "recv_size" : 0, "total_time_nsec" : 58126000, "standard_deviation_nsec" : 5895 }, {"send_size" : 64, "recv_size" : 4, "total_time_nsec" : 58927000, "standard_deviation_nsec" : 8933 }, {"send_size" : 64, "recv_size" : 8, "total_time_nsec" : 58163000, "standard_deviation_nsec" : 6663 }, {"send_size" : 64, "recv_size" : 16, "total_time_nsec" : 59901000, "standard_deviation_nsec" : 8340 }, {"send_size" : 64, "recv_size" : 32, "total_time_nsec" : 60365000, "standard_deviation_nsec" : 6319 }, {"send_size" : 64, "recv_size" : 64, "total_time_nsec" : 61776000, "standard_deviation_nsec" : 7461 }, {"send_size" : 64, "recv_size" : 128, "total_time_nsec" : 66984000, "standard_deviation_nsec" : 6810 }, {"send_size" : 64, "recv_size" : 256, "total_time_nsec" : 73913000, "standard_deviation_nsec" : 8826 }, {"send_size" : 64, "recv_size" : 512, "total_time_nsec" : 88134000, "standard_deviation_nsec" : 8356 }, {"send_size" : 64, "recv_size" : 1024, "total_time_nsec" : 146932000, "standard_deviation_nsec" : 7571 }, {"send_size" : 128, "recv_size" : 0, "total_time_nsec" : 57616000, "standard_deviation_nsec" : 6158 }, {"send_size" : 128, "recv_size" : 4, "total_time_nsec" : 59091000, "standard_deviation_nsec" : 7458 }, {"send_size" : 128, "recv_size" : 8, "total_time_nsec" : 60263000, "standard_deviation_nsec" : 11999 }, {"send_size" : 128, "recv_size" : 16, "total_time_nsec" : 59238000, "standard_deviation_nsec" : 6102 }, {"send_size" : 128, "recv_size" : 32, "total_time_nsec" : 60783000, "standard_deviation_nsec" : 6244 }, {"send_size" : 128, "recv_size" : 64, "total_time_nsec" : 62975000, "standard_deviation_nsec" : 8947 }, {"send_size" : 128, "recv_size" : 128, "total_time_nsec" : 65742000, "standard_deviation_nsec" : 5907 }, {"send_size" : 128, "recv_size" : 256, "total_time_nsec" : 72402000, "standard_deviation_nsec" : 6601 }, {"send_size" : 128, "recv_size" : 512, "total_time_nsec" : 87457000, "standard_deviation_nsec" : 9004 }, {"send_size" : 128, "recv_size" : 1024, "total_time_nsec" : 148412000, "standard_deviation_nsec" : 10532 }, {"send_size" : 256, "recv_size" : 0, "total_time_nsec" : 58705000, "standard_deviation_nsec" : 7274 }, {"send_size" : 256, "recv_size" : 4, "total_time_nsec" : 58818000, "standard_deviation_nsec" : 5453 }, {"send_size" : 256, "recv_size" : 8, "total_time_nsec" : 59451000, "standard_deviation_nsec" : 6926 }, {"send_size" : 256, "recv_size" : 16, "total_time_nsec" : 60237000, "standard_deviation_nsec" : 5781 }, {"send_size" : 256, "recv_size" : 32, "total_time_nsec" : 61456000, "standard_deviation_nsec" : 5591 }, {"send_size" : 256, "recv_size" : 64, "total_time_nsec" : 62615000, "standard_deviation_nsec" : 7588 }, {"send_size" : 256, "recv_size" : 128, "total_time_nsec" : 68554000, "standard_deviation_nsec" : 7766 }, {"send_size" : 256, "recv_size" : 256, "total_time_nsec" : 74557000, "standard_deviation_nsec" : 8748 }, {"send_size" : 256, "recv_size" : 512, "total_time_nsec" : 87929000, "standard_deviation_nsec" : 9510 }, {"send_size" : 256, "recv_size" : 1024, "total_time_nsec" : 148522000, "standard_deviation_nsec" : 11394 }, {"send_size" : 512, "recv_size" : 0, "total_time_nsec" : 59697000, "standard_deviation_nsec" : 7825 }, {"send_size" : 512, "recv_size" : 4, "total_time_nsec" : 59427000, "standard_deviation_nsec" : 5706 }, {"send_size" : 512, "recv_size" : 8, "total_time_nsec" : 59538000, "standard_deviation_nsec" : 6863 }, {"send_size" : 512, "recv_size" : 16, "total_time_nsec" : 61139000, "standard_deviation_nsec" : 7645 }, {"send_size" : 512, "recv_size" : 32, "total_time_nsec" : 62203000, "standard_deviation_nsec" : 7985 }, {"send_size" : 512, "recv_size" : 64, "total_time_nsec" : 62577000, "standard_deviation_nsec" : 8118 }, {"send_size" : 512, "recv_size" : 128, "total_time_nsec" : 68722000, "standard_deviation_nsec" : 10581 }, {"send_size" : 512, "recv_size" : 256, "total_time_nsec" : 74290000, "standard_deviation_nsec" : 8931 }, {"send_size" : 512, "recv_size" : 512, "total_time_nsec" : 88635000, "standard_deviation_nsec" : 7771 }, {"send_size" : 512, "recv_size" : 1024, "total_time_nsec" : 149589000, "standard_deviation_nsec" : 11456 }, {"send_size" : 1024, "recv_size" : 0, "total_time_nsec" : 63243000, "standard_deviation_nsec" : 6331 }, {"send_size" : 1024, "recv_size" : 4, "total_time_nsec" : 64381000, "standard_deviation_nsec" : 8372 }, {"send_size" : 1024, "recv_size" : 8, "total_time_nsec" : 63481000, "standard_deviation_nsec" : 5608 }, {"send_size" : 1024, "recv_size" : 16, "total_time_nsec" : 65549000, "standard_deviation_nsec" : 8826 }, {"send_size" : 1024, "recv_size" : 32, "total_time_nsec" : 65485000, "standard_deviation_nsec" : 6822 }, {"send_size" : 1024, "recv_size" : 64, "total_time_nsec" : 67125000, "standard_deviation_nsec" : 9829 }, {"send_size" : 1024, "recv_size" : 128, "total_time_nsec" : 72680000, "standard_deviation_nsec" : 7641 }, {"send_size" : 1024, "recv_size" : 256, "total_time_nsec" : 79206000, "standard_deviation_nsec" : 9854 }, {"send_size" : 1024, "recv_size" : 512, "total_time_nsec" : 92418000, "standard_deviation_nsec" : 9107 }, {"send_size" : 1024, "recv_size" : 1024, "total_time_nsec" : 152392000, "standard_deviation_nsec" : 11124 } ] }, "download_speed" : { "byte_size" : 4194304, "results" : [ {"send_size" : 0, "recv_size" : 32, "total_time_nsec" : 7735630000 }, {"send_size" : 0, "recv_size" : 64, "total_time_nsec" : 3985169000 }, {"send_size" : 0, "recv_size" : 128, "total_time_nsec" : 2128791000 }, {"send_size" : 0, "recv_size" : 256, "total_time_nsec" : 1172077000 }, {"send_size" : 0, "recv_size" : 512, "total_time_nsec" : 703833000 }, {"send_size" : 0, "recv_size" : 1024, "total_time_nsec" : 594966000 } ] } } llvm-svn: 237953
OpenPOWER on IntegriCloud