summaryrefslogtreecommitdiffstats
path: root/lldb/tools/debugserver
Commit message (Collapse)AuthorAgeFilesLines
...
* 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
* When debugserver is running on an iOS device, callJason Molenda2015-07-071-0/+3
| | | | | | | | | | proc_set_wakemon_params() to raise the limit on the # of wakeups per second that are acceptable before the system may send an EXC_RESOURCE signal to debugserver. <rdar://problem/19631512> llvm-svn: 241553
* More packet reduction when debugging with GDB server.Greg Clayton2015-06-291-0/+19
| | | | | | | | | - 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
* Use the right ifdef macro, reviewed by JasonHan Ming Ong2015-06-263-6/+6
| | | | llvm-svn: 240739
* rdar://problem/21469556Han Ming Ong2015-06-253-17/+44
| | | | | | Make sure that the memory report is correct for 64-bit devices. llvm-svn: 240728
* Commit file that was missing 240466.Greg Clayton2015-06-251-0/+490
| | | | | | <rdar://problem/21494354> llvm-svn: 240712
* Resubmitting 240466 after fixing the linux test suite failures.Greg Clayton2015-06-253-6/+197
| | | | | | | | | | | | | | | 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
* Implement the "qSymbol" packet in order to be able to read queue information ↵Greg Clayton2015-06-234-11/+382
| | | | | | | | | | | | | | 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
* Revert "Reduced packet counts to the remote GDB server where possible."Chaoren Lin2015-06-234-687/+6
| | | | | | | | | | 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-224-6/+687
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We have been working on reducing the packet count that is sent between LLDB and the debugserver on MacOSX and iOS. Our approach to this was to reduce the packets required when debugging multiple threads. We currently make one qThreadStopInfoXXXX call (where XXXX is the thread ID in hex) per thread except the thread that stopped with a stop reply packet. In order to implement multiple thread infos in a single reply, we need to use structured data, which means JSON. The new jThreadsInfo packet will attempt to retrieve all thread infos in a single packet. The data is very similar to the stop reply packets, but packaged in JSON and uses JSON arrays where applicable. The JSON output looks like: [ { "tid":1580681, "metype":6, "medata":[2,0], "reason":"exception", "qaddr":140735118423168, "registers": { "0":"8000000000000000", "1":"0000000000000000", "2":"20fabf5fff7f0000", "3":"e8f8bf5fff7f0000", "4":"0100000000000000", "5":"d8f8bf5fff7f0000", "6":"b0f8bf5fff7f0000", "7":"20f4bf5fff7f0000", "8":"8000000000000000", "9":"61a8db78a61500db", "10":"3200000000000000", "11":"4602000000000000", "12":"0000000000000000", "13":"0000000000000000", "14":"0000000000000000", "15":"0000000000000000", "16":"960b000001000000", "17":"0202000000000000", "18":"2b00000000000000", "19":"0000000000000000", "20":"0000000000000000"}, "memory":[ {"address":140734799804592,"bytes":"c8f8bf5fff7f0000c9a59e8cff7f0000"}, {"address":140734799804616,"bytes":"00000000000000000100000000000000"} ] } ] It contains an array of dicitionaries with all of the key value pairs that are normally in the stop reply packet. Including the expedited registers. Notice that is also contains expedited memory in the "memory" key. Any values in this memory will get included in a new L1 cache in lldb_private::Process where if a memory read request is made and that memory request fits into one of the L1 memory cache blocks, it will use that memory data. If a memory request fails in the L1 cache, it will fall back to the L2 cache which is the same block sized caching we were using before these changes. This allows a process to expedite memory that you are likely to use and it reduces packet count. On MacOSX with debugserver, we expedite the frame pointer backchain for a thread (up to 256 entries) by reading 2 pointers worth of bytes at the frame pointer (for the previous FP and PC), and follow the backchain. Most backtraces on MacOSX and iOS now don't require us to read any memory! We will try these packets out and if successful, we should port these to lldb-server in the near future. <rdar://problem/21494354> llvm-svn: 240354
* Add a new wart, I mean feature, on to gdb-remote protocol: compression.Jason Molenda2015-06-183-14/+352
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | For some communication channels, sending large packets can be very slow. In those cases, it may be faster to compress the contents of the packet on the target device and decompress it on the debug host system. For instance, communicating with a device using something like Bluetooth may be an environment where this tradeoff is a good one. This patch adds a new field to the response to the "qSupported" packet (which returns a "qXfer:features:" response) -- SupportedCompressions and DefaultCompressionMinSize. These tell you what the remote stub can support. lldb, if it wants to enable compression and can handle one of those algorithms, it can send a QEnableCompression packet specifying the algorithm and optionally the minimum packet size to use compression on. lldb may have better knowledge about the best tradeoff for a given communication channel. I added support to debugserver an lldb to use the zlib APIs (if -DHAVE_LIBZ=1 is in CFLAGS and -lz is in LDFLAGS) and the libcompression APIs on Mac OS X 10.11 and later (if -DHAVE_LIBCOMPRESSION=1). libz "zlib-deflate" compression. libcompression can support deflate, lz4, lzma, and a proprietary lzfse algorithm. libcompression has been hand-tuned for Apple hardware so it should be preferred if available. debugserver currently only adds the SupportedCompressions when it is being run on an Apple watch (TARGET_OS_WATCH). Comment that #if out from RNBRemote.cpp if you want to enable it to see how it works. I haven't tested this on a native system configuration but surely it will be slower to compress & decompress the packets in a same-system debug session. I haven't had a chance to add support for this to GDBRemoteCommunciationServer.cpp yet. <rdar://problem/21090180> llvm-svn: 240066
* Fix a variety of typos.Bruce Mitchener2015-06-181-1/+1
| | | | | | No functional change. llvm-svn: 239995
* Make the function that parses the json packets in debugserverJason Molenda2015-06-041-5/+17
| | | | | | | | a little more resilient to freely formatted json. Greg's change in r238279 made the json output from StructuredData unconditionally pretty-printed and the spaces were confusing debugserver. llvm-svn: 239013
* Add '+' sign at the end of echo message for debugserverYing Chen2015-05-291-1/+1
| | | | | | | | | | | | | | | | | | Summary: -ammend to r238538 -Fix test failure of TestGdbRemoteAuxvSupport.py and TestLldbGdbServer.py on MacOSX Test Plan: ./dotest -p TestGdbRemoteAuxvSupport.py ./dotest -p TestLldbGdbServer.py Reviewers: chaoren, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D10133 llvm-svn: 238595
* Add a new "qEcho" packet with the following format:Greg Clayton2015-05-292-1/+14
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Added XML to the host layer.Greg Clayton2015-05-266-22/+434
| | | | | | | | | | | | 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
* qProcessInfo was not correctly detecting the sysctl value for ↵Greg Clayton2015-05-071-4/+2
| | | | | | | | | | "hw.cpu64bit_capable". It was just detecting the existance of the value. If it gets the value correctly, we need to check that it is non-zero to see if cpu64bit_capable should be true. <rdar://problem/20857426> llvm-svn: 236759
* Build fix for building debugserver for ios.Jason Molenda2015-03-172-2/+2
| | | | llvm-svn: 232563
* Fix debugserver warnings on MacOSX.Greg Clayton2015-03-0932-693/+194
| | | | llvm-svn: 231692
* Bump major vers # in xcode project file from 330 to 340.Jason Molenda2015-03-061-8/+8
| | | | llvm-svn: 231441
* Fix a thinko in the case where we return a launch error with no errorJim Ingham2015-03-041-1/+1
| | | | | | | | string. Return "<unknown error>" rather than the empty launch error... <rdar://problem/20026469> llvm-svn: 231287
* Separate monolithic GDBRemoteCommunicationServer class into 4 partTamas Berghammer2015-02-111-1/+1
| | | | | | | | | | | GDBRemoteCommunicationServer: Basic packet handling, handler registration LLDBCommonPacketHandler: Common packet handling for lldb-platform and lldb-gdbserver LLDBPlatformPacketHandler: lldb-platform specific packet handling LLGSPacketHandler: lldb-gdbserver specific packet handling Differential Revision: http://reviews.llvm.org/D7538 llvm-svn: 228823
* Add comments explaining the unwind setup inJason Molenda2015-01-161-0/+22
| | | | | | | | | ABIMacOSX_i386::CreateFunctionEntryUnwindPlan, ABIMacOSX_i386::CreateDefaultUnwindPlan, ABISysV_x86_64::CreateFunctionEntryUnwindPlan, ABISysV_x86_64::CreateDefaultUnwindPlan llvm-svn: 226347
* Fixes to DNBArchImpl in debugserver to correctly get/setJason Molenda2015-01-162-11/+187
| | | | | | | | | | | | | the register state when debugging AArch32 programs (armv7 programs running on an armv8 processor). Most notably, there is no "fpscr" register in the register context - there is an fpsr and an fpcr. Also fix a bug where the floating point values could not be written in armv7 processes. <rdar://problem/18977767> llvm-svn: 226244
* Make sure x7 and x8 are treated as argument registers for arm64.Greg Clayton2015-01-051-2/+2
| | | | llvm-svn: 225193
* Handle thumb IT instructions correctly all the time.Greg Clayton2014-12-091-3/+13
| | | | | | | | | | | | | | | | | | | | | | The issue with Thumb IT (if/then) instructions is the IT instruction preceeds up to four instructions that are made conditional. If a breakpoint is placed on one of the conditional instructions, the instruction either needs to match the thumb opcode size (2 or 4 bytes) or a BKPT instruction needs to be used as these are always unconditional (even in a IT instruction). If BKPT instructions are used, then we might end up stopping on an instruction that won't get executed. So if we do stop at a BKPT instruction, we need to continue if the condition is not true. When using the BKPT isntructions are easy in that you don't need to detect the size of the breakpoint that needs to be used when setting a breakpoint even in a thumb IT instruction. The bad part is you will now always stop at the opcode location and let LLDB determine if it should auto-continue. If the BKPT instruction is used, the BKPT that is used for ARM code should be something that also triggers the BKPT instruction in Thumb in case you set a breakpoint in the middle of code and the code is actually Thumb code. A value of 0xE120BE70 will work since the lower 16 bits being 0xBE70 happens to be a Thumb BKPT instruction. The alternative is to use trap or illegal instructions that the kernel will translate into breakpoint hits. On Mac this was 0xE7FFDEFE for ARM and 0xDEFE for Thumb. The darwin kernel currently doesn't recognize any 32 bit Thumb instruction as a instruction that will get turned into a breakpoint exception (EXC_BREAKPOINT), so we had to use the BKPT instruction on Mac. The linux kernel recognizes a 16 and a 32 bit instruction as valid thumb breakpoint opcodes. The benefit of using 16 or 32 bit instructions is you don't stop on opcodes in a IT block when the condition doesn't match. To further complicate things, single stepping on ARM is often implemented by modifying the BCR/BVR registers and setting the processor to stop when the PC is not equal to the current value. This means single stepping is another way the ARM target can stop on instructions that won't get executed. This patch does the following: 1 - Fix the internal debugserver for Apple to use the BKPT instruction for ARM and Thumb 2 - Fix LLDB to catch when we stop in the middle of a Thumb IT instruction and continue if we stop at an instruction that won't execute 3 - Fixes this in a way that will work for any target on any platform as long as it is ARM/Thumb 4 - Adds a patch for ignoring conditions that don't match when in ARM mode (see below) This patch also provides the code that implements the same thing for ARM instructions, though it is disabled for now. The ARM patch will check the condition of the instruction in ARM mode and continue if the condition isn't true (and therefore the instruction would not be executed). Again, this is not enable, but the code for it has been added. <rdar://problem/19145455> llvm-svn: 223851
* Remove unused service plist.Jason Molenda2014-10-302-17/+0
| | | | llvm-svn: 220892
* Clarify the launch style for debugserver to use.Jason Molenda2014-10-283-7/+5
| | | | | | <rdar://problem/18786645> llvm-svn: 220761
* Enable warnings in the debugserver project file..Jason Molenda2014-10-161-1/+17
| | | | llvm-svn: 219917
* Xcode recommended these changes to the project file. It recommendedJason Molenda2014-10-161-1/+1
| | | | | | | a number of warnings to be enabled. The one making the most noise across the code base right now is CLANG_WARN_UNREACHABLE_CODE = YES. llvm-svn: 219910
* Fix unused-variable warnings from the clang static analyzer.Jason Molenda2014-10-155-11/+5
| | | | llvm-svn: 219863
* Rework the way we pass "run multiple command" options to the various API's thatJim Ingham2014-10-111-3/+5
| | | | | | | | | | | | | | | do that (RunCommandInterpreter, HandleCommands, HandleCommandsFromFile) to gather the options into an options class. Also expose that to the SB API's. Change the way the "-o" options to the lldb driver are processed so: 1) They are run synchronously - didn't really make any sense to run the asynchronously. 2) The stop on error 3) "quit" in one of the -o commands will not quit lldb - not the command interpreter that was running the -o commands. I added an entry to the run options to stop-on-crash, but I haven't implemented that yet. llvm-svn: 219553
* Fix codesigning of MacOSX debugserver when built with cmake.Todd Fiala2014-10-022-2/+4
| | | | | | | | | | | | | | | | This patch fixes the codesigning of debugserver on OSX when built with cmake. Without this you get this error when debugging: error: process launch failed: unable to locate debugserver Note: you also need to set LLDB_DEBUGSERVER_PATH to point to your built debugserver. e.g. export LLDB_DEBUGSERVER_PATH=`pwd`/bin/debugserver Change by dawn@burble.org. Tested on MacOSX 10.9.5 and Xcode 6.1 Beta using cmake/ninja. Verified no build break on Linux Ubuntu cmake/ninja and Xcode 6.1 canonical build. llvm-svn: 218890
* rdar://problem/18221417Han Ming Ong2014-09-031-1/+1
| | | | | | Include compressed memory as part of gauge memory. llvm-svn: 217084
* Bump the verison number in the xcode project files.Jason Molenda2014-08-211-8/+8
| | | | llvm-svn: 216245
* Add comment explaining the dwarf v. eh_frame register numbering usedJason Molenda2014-08-131-1/+6
| | | | | | on i386 darwin. llvm-svn: 215484
* Increase the gdb-remote packet timeout for the first packet we sendJason Molenda2014-07-246-0/+115
| | | | | | | | | | | | | to the remote side (QStartNoAckMode) - it may take a little longer than normal to get a reply. In debugserver, hardcode the priority for several threads so they aren't de-prioritized when a user app is using system resources. Also, set the names of the threads. <rdar://problem/17509866> llvm-svn: 213828
* __arm64__ and __aarch64__ #ifdef adjustmentsTodd Fiala2014-07-099-32/+32
| | | | | | | | Change by Paul Osmialowski See http://reviews.llvm.org/D4379 for details. llvm-svn: 212583
OpenPOWER on IntegriCloud