summaryrefslogtreecommitdiffstats
path: root/lldb/tools/debugserver/source
Commit message (Collapse)AuthorAgeFilesLines
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-06103-33925/+32473
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* Fix darwin cmake build for r279997Pavel Labath2016-08-301-1/+1
| | | | llvm-svn: 280087
* Copy StringExtractor to StdStringExtractor.Zachary Turner2016-08-293-16/+16
| | | | | | | | | | | I have some improvements to make to StringExtractor that require using LLVM. debugserver can't take a dependency on LLVM but uses this file, so I'm forking it off into StdStringExtractor and StringExtractor, so that StringExtractor can take advantage of some performance improvements and readability improvements that LLVM can provide. llvm-svn: 279997
* Fix warnings preventing copy elision.Pavel Labath2016-08-251-10/+10
| | | | | | | | | | | | | | | | | Summary: Moving a temporary object prevents copy elision, which is exactly what clang points out by warning about this pattern. The fix is simply removal of std::move applied to temporary objects. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D23825 Author: Taras Tsugrii <ttsugrii@fb.com> llvm-svn: 279724
* Add StructuredData plugin type; showcase with new DarwinLog featureTodd Fiala2016-08-1935-29/+3527
| | | | | | | | | | | | Take 2, with missing cmake line fixed. Build tested on Ubuntu 14.04 with clang-3.6. See docs/structured_data/StructuredDataPlugins.md for details. differential review: https://reviews.llvm.org/D22976 reviewers: clayborg, jingham llvm-svn: 279202
* Revert "Add StructuredData plugin type; showcase with new DarwinLog feature"Todd Fiala2016-08-1935-3527/+29
| | | | | | This reverts commit 1d885845d1451e7b232f53fba2e36be67aadabd8. llvm-svn: 279200
* Add StructuredData plugin type; showcase with new DarwinLog featureTodd Fiala2016-08-1935-29/+3527
| | | | | | | | | See docs/structured_data/StructuredDataPlugins.md for details. differential review: https://reviews.llvm.org/D22976 reviewers: clayborg, jingham llvm-svn: 279198
* Switch over to using socketpair for local debugserver connections as they ↵Greg Clayton2016-08-121-1/+46
| | | | | | | | | | | | | | | | are twice as fast as TCP sockets (on macOS at least). This change opens a socket pair and passes the second socket pair file descriptor down to the debugserver binary using a new option: "--fd=N" where N is the file descriptor. This file descriptor gets passed via posix_spawn() so that there is no need to do any bind/listen or bind/accept calls and eliminates the hanshake unix socket that is used to pass the result of the actual port that ends up being used so it can save time on launch as well as being faster. This is currently only enabled on __APPLE__ builds. Other OSs should try modifying the #define from ProcessGDBRemote.cpp but the first person will need to port the --fd option over to lldb-server. Any OSs that enable USE_SOCKETPAIR_FOR_LOCAL_CONNECTION in their native builds can use the socket pair stuff. The #define is Apple only right now, but looks like: #if defined (__APPLE__) #define USE_SOCKETPAIR_FOR_LOCAL_CONNECTION 1 #endif <rdar://problem/27814880> llvm-svn: 278524
* Undo usage of LLVM macros in debugserverTodd Fiala2016-08-101-2/+2
| | | | | | | We don't take a dependency on LLVM in debugserver. This was failing to compile before. llvm-svn: 278190
* Delete Host/windows/win32.hZachary Turner2016-08-092-5/+5
| | | | | | | | | | | | | | | | | | | It's always hard to remember when to include this file, and when you do include it it's hard to remember what preprocessor check it needs to be behind, and then you further have to remember whether it's windows.h or win32.h which you need to include. This patch changes the name to PosixApi.h, which is more appropriately named, and makes it independent of any preprocessor setting. There's still the issue of people not knowing when to include this, because there's not a well-defined set of things it exposes other than "whatever is missing on Windows", but at least this should make it less painful to fix when problems arise. This patch depends on LLVM revision r278170. llvm-svn: 278177
* [debugserver] Delete CFData.{h,cpp}, since they appear to be dead (NFCI)Vedant Kumar2016-08-094-114/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D23070 llvm-svn: 278142
* [lldb] Delete dead, infinitely-recursive code (NFC)Vedant Kumar2016-08-012-12/+0
| | | | | | Differential Revision: https://reviews.llvm.org/D22985 llvm-svn: 277351
* Try to fix the OSX build with old SDK after r274725Tamas Berghammer2016-07-071-2/+12
| | | | llvm-svn: 274743
* debugserver will now report the minimum version load commandJason Molenda2016-07-072-0/+47
| | | | | | | | | | | | os name and version # from the mach-o binary as it scans the header/load commands from memory and sends the details back in the jGetLoadedDynamicLibrariesInfos response. lldb isn't using these fields yet but I have a suspicion I'm going to need them soon. <rdar://problem/25251243> llvm-svn: 274725
* Add support to debugserver for some new ways to interact with dyldJason Molenda2016-07-076-174/+611
| | | | | | | | | | | | to find the solibs loaded in a process. Support two new ways of sending the jGetLoadedDynamicLibrariesInfos packet to debugserver and add a new jGetSharedCacheInfo packet. Update the documentation for these packets as well. The changes to lldb to use these will be a separate commit. <rdar://problem/25251243> llvm-svn: 274718
* 64-bit LEB values are not always correctly decoded due to a casting issue, ↵Greg Clayton2016-06-281-2/+2
| | | | | | | | now they are. <rdar://problem/27002247> llvm-svn: 274037
* Change the "debugserver-mini" target (a version of debugserverJason Molenda2016-06-211-5/+16
| | | | | | | | | | | | | | | | | | which doesn't like against all the extra UI frameworks on ios) so it now generates a binary called "debugserver-nonui" and puts it in /usr/local/bin instead of /Developer/usr/bin. Add some cruft to RNBDefs.h to get the version number (provided by Xcode at build time) with either the name "debugserver" or "debugserver_nonui" as appropriate. Add the "debugserver-mini" target to the top level "ios" target in lldb xcode project file, so this nonui debugserver will be built along with the normal lldb / debugserver. <rdar://problem/24730789> llvm-svn: 273236
* [cmake] Add ability to customize (and skip) debugserver codesignPavel Labath2016-05-261-23/+25
| | | | | | | | | | | | | | | | | | Summary: This adds the ability to customize the debugserver codesign process via cmake cache variable. The user can set the codesign indentity (with the default being the customary lldb_codesign), and if the identity is set to a empty string, the codesign step is skipped completely. We needed the last feature to enable building lldb on buildservers which do not have the right certificates installed. Reviewers: sas, tberghammer Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D20623 llvm-svn: 270832
* Check that __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ is definedJason Molenda2016-05-191-1/+1
| | | | | | | before comparing the value of it. <rdar://problem/26333564> llvm-svn: 270015
* Fix an issue where debugserver would not properly vend OS version ↵Enrico Granata2016-05-181-7/+5
| | | | | | | | | | | information on iOS devices The __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED macro is only defined on OS X, so the check as written compiled the code out for iOS The right thing to do is compile the code out for older OSX versions, but leave iOS alone rdar://26333564 llvm-svn: 270004
* Don't crash when a process' task port goes bad.Greg Clayton2016-05-121-1/+0
| | | | | | <rdar://problem/26256049> llvm-svn: 269373
* debugserver; fix -Wunused-local-typedef, -Wunused-variable warningsSaleem Abdulrasool2016-05-061-7/+0
| | | | | | | Remove the typedef and local structure which was unused. Fixes last of the new clang warnings in the debugserver build. NFC. llvm-svn: 268759
* debugserver: fix a couple of -Wmissing-field-initializers warningsSaleem Abdulrasool2016-05-061-1/+3
| | | | | | | Explicitly provide an initializer for the std::vector in the constructed type. Addresses -Wmissing-field-initializers warnings from clang. NFC. llvm-svn: 268758
* debugserver: fix some -Wpessimizing-move warningsSaleem Abdulrasool2016-05-061-3/+3
| | | | | | | Remove the unnecessary use of std::move to permit the compiler to perform NVRO instead. Fixes more warnings from clang. NFC. llvm-svn: 268757
* debugserver: fix a few -Wcovered-swift-default warningsSaleem Abdulrasool2016-05-062-2/+0
| | | | | | | | Remove a couple of `default` cases from switches which are covered. This is beneficial since it would allow the compiler to indicate when a new enum value is added and the switch is not updated. Fixes some warnings from clang. NFC. llvm-svn: 268756
* debugserver: fix some -Wformat-pedantic warningsSaleem Abdulrasool2016-05-061-16/+7
| | | | | | | Perform explicit casts for the log message to address some `-Wformat-pedantic` warnings from clang. NFC. llvm-svn: 268755
* 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
* 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-284-138/+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
* [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-2314-279/+907
| | | | | | | | | | | | 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
OpenPOWER on IntegriCloud