summaryrefslogtreecommitdiffstats
path: root/lldb/tools/debugserver
Commit message (Collapse)AuthorAgeFilesLines
* debugserver should fflush its log stream in FileLogCallback, now it does.Greg Clayton2016-05-021-2/+3
| | | | | | <rdar://problem/24728287> llvm-svn: 268325
* Fixed an issue that could cause debugserver to return two stop reply packets ↵Greg Clayton2016-04-012-0/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | ($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
* Bump the lldb version # in the xcode project files fromJason Molenda2016-03-151-19/+19
| | | | | | 350.99.0 to 360.99.0. llvm-svn: 263529
* Removed unused functions.Greg Clayton2016-02-242-105/+0
| | | | llvm-svn: 261768
* Add a missing break.Jim Ingham2016-02-101-1/+1
| | | | llvm-svn: 260345
* If we set the DYLD_INSERT_LIBRARIES environment variable when launching ↵Greg Clayton2016-02-091-0/+4
| | | | | | debugserver, for use with /usr/lib/libgmalloc.dylib, then make sure we don't pass this environment variable on to any child processes. llvm-svn: 260284
* Remove autoconf support from source directories.Eugene Zelenko2016-01-285-151/+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-8/+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
* Fixed some #ifdefs. We were erroneously not supporting certain simulators.Sean Callanan2016-01-201-2/+2
| | | | | | | | We had some #ifdefs that were looking for the wrong #defines and as a result debugserver didn't have support for certain simulators. This patch resolves the problem. llvm-svn: 258365
* Changes to lldb and debugserver to reduce extraneous memory readsJason Molenda2016-01-122-38/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* In the questionmark packet ("T"), print the "threads:" and "thread-pcs:"Jason Molenda2016-01-081-30/+30
| | | | | | | | keys before we print the libdispatch queues keys (qname, qkind, qserialnum) to make it easier to read the packet by hand. No function difference, just reordering the keys in the output. llvm-svn: 257229
* Change the key name for the libdispatch queue serial number fromJason Molenda2016-01-081-2/+2
| | | | | | | | | "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
* Add a new "thread-pcs" key-value pair to the T packet response fromJason Molenda2015-12-151-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | debugserver. thread-pcs has a comma separated list of base 16 addresses - the current pc value for every thread in the process. It is a partner of the "threads:" key where a list of thread IDs is given. The pc values in thread-pcs correspond one-to-one with the thread IDs in the threads list. This is a part of performance work. When lldb is instruction stepping / fast stepping over a range of addresses for e.g. a "next" command, and it steps in to another function, lldb will put a breakpoint on the return address and continue the process. Before it calls continue, it calls Thread::SetupForResume on all the threads, and SetupForResume needs to get the current pc value for every thread to see if any are at a breakpoint site. The result is that issuing a "c" continue requires that we send "read pc register" packets for every thread. We may do this sequence of step-into-function / continue-to-get-out many times for a single user-visible "next" or "step" command, and with highly multithreaded programs, we are sending many extra packets to get all the thread values. I looked at including this data in the "jstopinfo" JSON that we already have in the T packet. But there are three problems that would make this increase the size of the T packet significantly. First, numbers in JSON are base 10. Second, a proper JSON would have something like "thread_pcs": { "34224331112":383772734222, ...} for thread-id 34224331112 and pc 383772734222 - so we're including a whole extra copy of the thread id in addition to the pc. Third, the JSON text is hex-ascii'fied so the size of it is doubled. In one example, threads:585db8,585dc7,585dc8,585dc9,585dca,585dce;thread-pcs:100001400,7fff8badc6de,7fff8badcff6,7fff8badc6de,7fff8badc6de,7fff8badc6de; The "thread-pcs" adds 86 characters - 136 characters for both threads and thread-pcs. Doing this in JSON would look like threads={"5791160":4294972416,"5791175":140735536809694,"5791176":140735536812022,"5791177":140735536809694,"5791178":140735536809694,"5791182":140735536809694} or 160 characters -- or 320 characters once it is hex-asciified. Given that it's 86 characters vrs 320, I went with the old style approach. I've seen real world programs that have up to 60 threads in them, so this could result in vastly larger packets if it was all done in the JSON with hex-ascii expansion. If we had an all-JSON T packet, where we didn't need to hex-ascii encode anything, that would have been the better approach. But we'd already have a list of threads in JSON at that point so the additional text wouldn't be too bad. I'm working on finishing the patches to lldb to use this data; will commit those once I've had a chance to test them more. But I wanted to commit the debugserver bits which are more straightforward. <rdar://problem/21963031> llvm-svn: 255711
* When supplying memory to expedite the unwinds in the T packet,Jason Molenda2015-12-121-1/+1
| | | | | | | | | include two stack frames worth of unwind information instead of just one -- the unwinder is trying to fetch two stack frames in more instances now and we're sending extra memory reads resulting in a performance degredation while stepping. llvm-svn: 255417
* Squelch a silly warning regarding an extra 'default' in 'case'Ramkumar Ramachandra2015-11-031-39/+38
| | | | | | | | | | | | Let the editor also clean up whitespace for that file. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13816 llvm-svn: 251979
* Xcode suggested enabling a "no common blocks" warningJason Molenda2015-10-292-9/+22
| | | | | | | (whatever that is) and wanted to clean up some duplicated entries in the project files. llvm-svn: 251586
* Remove some unnecessary macosx.internal SDK settings inJason Molenda2015-10-251-9/+9
| | | | | | the debugserver xcode project file. llvm-svn: 251221
* [debugserver] Fix OSX build for older XCode versions after r251091.Dawn Perchik2015-10-241-0/+4
| | | | | | | | | | | | This fixes the OSX build for XCode versions older than 7 by skipping references to LC_VERSION_MIN_TVOS and LC_VERSION_MIN_WATCHOS if TARGET_OS_TV or TARGET_OS_WATCH aren't defined. Reviewed by: jasonmolenda Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D14036 llvm-svn: 251172
* [debugserver] Fix indentation in RNBRemote.cpp.Dawn Perchik2015-10-241-77/+77
| | | | llvm-svn: 251169
* Remove some tabs that snuck into debugserver-entitlements.plist, etc.Jason Molenda2015-10-232-14/+12
| | | | llvm-svn: 251092
* Upstreaming the apple internal changes that accumulated during theJason Molenda2015-10-2315-307/+1920
| | | | | | | | | | | | previous release. Most of the diffs are duplication in the xcode project file caused by adding a "debugserver-mini" target. Jim Ingham added support for a new SPI needed to request app launches on iOS. Greg Clayton added code to indicate the platform of the binary (macosx, ios, watchos, tvos) based on Mach-O load commands. Jason Molenda added code so debugserver will identify when it is running on a tvos/watchos device to lldb. llvm-svn: 251091
* [cmake] Fix cmake build on OSX after r250335 for older versions of cmakeDawn Perchik2015-10-221-6/+16
| | | | | | | | Reviewed by: sas Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13995 llvm-svn: 251073
* Fix codesign command with cmake.Stephane Sezer2015-10-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | Summary: Looks like having a space in the Xcode path triggers this bug. We need to use cmake -E env FOO=bar [COMMAND] to set the environment instead. I am using cmake 3.3.1 and ninja 1.6.0 and I get this: [2681/2756] Linking CXX executable bin/debugserver FAILED: : && /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/c++ -fPIC -fvisibility-inlines-hidden -Wall -W -Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers -pedantic -Wno-long-long -Wcovered-switch-default -std=c++11 -fcolor-diagnostics -Wno-deprecated-declarations -Wno-unknown-pragmas -Wno-deprecated-register -Wno-vla-extension -fno-exceptions -fno-rtti -Wno-gnu-zero-variadic-macro-arguments -Wno-zero-length-array -Wno-extended-offsetof -g -Wl,-search_paths_first -Wl,-headerpad_max_install_names -stdlib=libc++ -Wl,-sectcreate,__TEXT,__info_plist,/Users/sas/Source/llvm/tools/lldb/tools/debugserver/source/../resources/lldb-debugserver-Info.plist tools/lldb/tools/debugserver/source/MacOSX/CMakeFiles/debugserver.dir/HasAVX.s.o tools/lldb/tools/debugserver/source/MacOSX/CMakeFiles/debugserver.dir/CFBundle.cpp.o tools/lldb/tools/debugserver/source/MacOSX/CMakeFiles/debugserver.dir/CFData.cpp.o tools/lldb/tools/debugserver/source/MacOSX/CMakeFiles/debugserver.dir/CFString.cpp.o tools/lldb/tools/debugserver/source/MacOSX/CMakeFiles/debugserver.dir/Genealogy.cpp.o tools/lldb/tools/debugserver/source/MacOSX/CMakeFiles/debugserver.dir/MachException.cpp.o tools/lldb/tools/debugserver/source/MacOSX/CMakeFiles/debugserver.dir/MachProcess.mm.o tools/lldb/tools/debugserver/source/MacOSX/CMakeFiles/debugserver.dir/MachTask.mm.o tools/lldb/tools/debugserver/source/MacOSX/CMakeFiles/debugserver.dir/MachThread.cpp.o tools/lldb/tools/debugserver/source/MacOSX/CMakeFiles/debugserver.dir/MachThreadList.cpp.o tools/lldb/tools/debugserver/source/MacOSX/CMakeFiles/debugserver.dir/MachVMMemory.cpp.o tools/lldb/tools/debugserver/source/MacOSX/CMakeFiles/debugserver.dir/MachVMRegion.cpp.o tools/lldb/tools/debugserver/source/MacOSX/CMakeFiles/debugserver.dir/mach_excServer.c.o tools/lldb/tools/debugserver/source/MacOSX/CMakeFiles/debugserver.dir/mach_excUser.c.o tools/lldb/tools/debugserver/source/MacOSX/CMakeFiles/debugserver.dir/debugserver_vers.c.o -o bin/debugserver lib/liblldbDebugserverCommon.a lib/liblldbUtility.a lib/liblldbDebugserverMacOSX_I386.a lib/liblldbDebugserverMacOSX_X86_64.a -framework Cocoa -Wl,-rpath,@executable_path/../lib && cd /Users/sas/Source/llvm/build/bin && "CODESIGN_ALLOCATE=/Applications/Xcode 6.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate" codesign --force --sign lldb_codesign debugserver /bin/sh: CODESIGN_ALLOCATE=/Applications/Xcode 6.4.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/codesign_allocate: No such file or directory [2681/2756] Building CXX object tools/lldb/source/Target/CMakeFiles/lldbTarget.dir/Target.cpp.o ninja: build stopped: subcommand failed. Reviewers: clayborg, dawn, brucem, tfiala Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13742 llvm-svn: 250335
* [debugserver,cmake] Add DEPENDS to custom commands.Bruce Mitchener2015-10-091-1/+5
| | | | | | | | | | | | | | Summary: Add dependencies to the custom commands so that they get re-executed as needed. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13580 llvm-svn: 249860
* Fix typos.Bruce Mitchener2015-09-221-1/+1
| | | | | | | | | | | | Summary: Another round of minor typo fixes. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D13026 llvm-svn: 248243
* A partner to the cleanup in r247741, change the variables names inJason Molenda2015-09-158-560/+449
| | | | | | | | | | | | | | debugserver to match. "gcc" is now "ehframe" and "gdb" is now "debugserver". Because this is debugserver, what we call the Process Plugin register numbers up in lldb are the debugserver register numbers down here - they are the register numbers that debugserver will use to refer to these registers over the gdb-remote protocol. debugserver was already reporting the registers with the key "ehframe"; this change is just cleaning up the internal variable names to match. llvm-svn: 247751
* Clean up register naming conventions inside lldb. Jason Molenda2015-09-151-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "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
* [cmake] Remove LLVM_NO_RTTI.Bruce Mitchener2015-09-034-8/+0
| | | | | | | | | | | | | | Summary: This doesn't exist in other LLVM projects any longer and doesn't do anything. Reviewers: chaoren, labath Subscribers: emaste, tberghammer, lldb-commits, danalbert Differential Revision: http://reviews.llvm.org/D12586 llvm-svn: 246749
* [debugserver] Fix sign comparison warning.Bruce Mitchener2015-09-012-1/+2
| | | | | | | | | | | | | | | | | Summary: Comparing m_page_size against kInvalidPageSize was resulting in a warning about comparing integers with different signs. Since kInvalidPageSize isn't used anywhere outside of MachVMMemory.cpp, we can readily transform it into a static const vm_size_t with the correct value to avoid the sign comparison warnings. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12519 llvm-svn: 246606
* Use -Wno-vla-extension globally.Bruce Mitchener2015-09-011-6/+0
| | | | | | | | | | | | | | | Summary: This was previously only established within debugserver, but there is a use of the VLA extension in source/Host/macosx/Symbols.cpp, so ignore this warning globally. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12515 llvm-svn: 246605
* Fix lldb build on older OSX versions after svn commit r244716Dawn Perchik2015-08-271-0/+2
| | | | | | | | | | | | | | Older OSX versions don't define NSOperatingSystemVersion, so building lldb gets: error: unknown type name 'NSOperatingSystemVersion' This patch fixes the build by having GetOSVersionNumbers return false if __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ < 101000, causing lldb to behave the same as it did before the commit. Reviewed by: jasonmolenda Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D12396 llvm-svn: 246138
* Quiet build warnings on MacOSX.Greg Clayton2015-08-181-2/+2
| | | | llvm-svn: 245373
* Add missing newline at EOF.Bruce Mitchener2015-08-131-1/+1
| | | | | | This fixes a warning on the Mac OS X build. llvm-svn: 244863
* Remove DNBConfig.hBruce Mitchener2015-08-1310-155/+3
| | | | | | | | | | | | | | | Summary: This was no longer needed and hasn't been needed since r143244 in 2011. This removes everything associated with generating or using it. Reviewers: clayborg, jasonmolenda Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11971 llvm-svn: 244850
* Have debugserver send the OS version string plusJason Molenda2015-08-125-0/+47
| | | | | | | | | | major, minor, and patchlevel in the qHostInfo reply. Document that qHostInfo may report major/minor/patch separately / in addition to the version: combination. <rdar://problem/22125465> llvm-svn: 244716
* [debugserver] Fix "control may reach end of non-void function" warnings.Bruce Mitchener2015-08-042-8/+9
| | | | | | | | | | Reviewers: clayborg, jingham Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11745 llvm-svn: 243953
* Bump the version # in the xcode proj file from major number 340 to 350.Jason Molenda2015-08-041-8/+8
| | | | | | The SB API for major version 340 won't be changing any more. llvm-svn: 243943
* Fix build of lldb on Mavericks after svn rev.243511.Dawn Perchik2015-07-311-2/+2
| | | | | | | | | | | | This patch adds a test for ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED around the code which requires 10.10 support to link. Without this, lldb gets unresolved references to _csr_check and _rootless_allows_task_for_pid. Reviewed by: jasonmolenda Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11668 llvm-svn: 243715
* When debugserver fails to attach to a process on a DarwinJason Molenda2015-07-293-6/+74
| | | | | | | | | | | | | | | | | | | 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
* Add UNUSED_IF_ASSERT_DISABLED and apply it.Bruce Mitchener2015-07-247-11/+13
| | | | | | | | | | | | | | | 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
* Fix Mac OS X build, debugserver version handling.Bruce Mitchener2015-07-242-3/+14
| | | | | | | | | | | | | | | | | | Summary: No longer rely on cmake to set DEBUGSERVER_VERSION_STR, but now generate the _vers.c file like xcode does and include the generated file into the build on Mac OS X. This fixes the cmake Mac OS X build after an earlier change by Jason Molenda. Reviewers: clayborg, jasonmolenda Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11450 llvm-svn: 243072
* Fix the variable used to reply to the qGDBServerVersionJason Molenda2015-07-221-1/+1
| | | | | | | | | | packet so that debugserver will send a reply like name:debugserver;version:340.99; <rdar://problem/21933963> llvm-svn: 242968
* Don't water JSONGenerator objects down into ObjectSP's too early so that we ↵Greg Clayton2015-07-221-31/+31
| | | | | | can call member functions specific to dictionaries and arrays without calling GetAsDictionary() or GetAsArray() on them. llvm-svn: 242917
* Fix warnings.Bruce Mitchener2015-07-2226-63/+98
| | | | | | | | | | Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11404 llvm-svn: 242913
* More packet performance improvements. Greg Clayton2015-07-173-48/+60
| | | | | | | | 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
* Only include the stack memory for the caller stackJason Molenda2015-07-161-3/+3
| | | | | | | | | | | | | | | frame, don't go any further, in RNBRemote::SendStopReplyPacketForThread. These are the memory pre-fetches in the T05 packet and are included in every private stop that lldb does. lldb needs, at most, the caller stack frame so we're sending more data than needed by including additional stack memory prefetches in this reply packet. Once we've stopped for a public stop, we're going to do a jThreadsInfo which will include the stack memory prefetches for all threads, including the one which had the stop reason. llvm-svn: 242380
* Added the ability to get JSON thread stop info with thread ID and stop info ↵Greg Clayton2015-07-152-62/+112
| | | | | | | | | | 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
* Fix debugserver build breakage on Mavericks after lldb commit svn 240728Dawn Perchik2015-07-141-2/+2
| | | | | | | | vm_kernel_page_size appears to not be defined on OSX Mavericks, so the build fails. This patch fixes the build by calculating the pagesize if _VM_PAGE_SIZE_H_ is not defined. llvm-svn: 242114
* Add a another packet to the gdb-remote protocol,Jason Molenda2015-07-106-0/+331
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix debugserver build after someone moved StrintExtractor.h.Greg Clayton2015-07-072-5/+5
| | | | llvm-svn: 241628
OpenPOWER on IntegriCloud