Commit Graph

161 Commits

Author SHA1 Message Date
Alex Langford 9391061fd7 Delete some dead code
llvm-svn: 334320
2018-06-08 21:13:26 +00:00
Adrian Prantl 6e9f77126b Silence compiler warning.
llvm-svn: 331375
2018-05-02 17:11:43 +00:00
Davide Italiano e185dcf13d Revert "[debugserver] Remove dead function call. NFCI."
This reverts commit r330066 as it was wrong and the call was
not dead. Thanks to Fred for pointing this out.

llvm-svn: 330071
2018-04-13 21:26:32 +00:00
Davide Italiano 0bd55b187e [debugserver] Remove dead function call. NFCI.
llvm-svn: 330066
2018-04-13 20:47:25 +00:00
Frederic Riss cd90f878d4 [debugserver] Fix LC_BUILD_VERSION load command handling.
Summary:
In one of the 2 places the LC_BUILD_VERSION load command is handled, there
is a bug preventing us from actually handling them (the address where to
read the load command was not updated). This patch factors reading the
deployment target load commands into a helper and adds testing for the 2
code paths calling the helper.

The testing is a little bit complicated because the only times those load
commands matter is when debugging a simulator process. I added a new
decorator to check that a specific SDK is available. The actual testing was
fairly easy once I knew how to run a simulated process.

Reviewers: jasonmolenda, labath

Subscribers: lldb-commits

Differential Revision: https://reviews.llvm.org/D45298

llvm-svn: 329374
2018-04-06 04:28:12 +00:00
Jason Molenda a1bd9508e0 Upstreaming avx512 register support in debugserver. These changes
were originally written by Chris Bieneman, they've undergone a
number of changes since then.

Also including the debugserver bridgeos support, another arm
environment that runs Darwin akin to ios.  These codepaths are
activated when running in a bridgeos environment which we're not
set up to test today.

There's additional (small) lldb changes to handle bridgeos binaries
that still need to be merged up.

Tested on a darwin system with avx512 hardware and without.

<rdar://problem/36424951> 

llvm-svn: 326756
2018-03-06 00:27:41 +00:00
Jason Molenda c4dd04c5c3 When parsing the target.xml register file, if no architecture has
been specified yet (either by the user, or by one of the lldb
extensions like qHostInfo or qProcessInfo), and the target.xml
includes a <architecture> tag specifying x86_64, set the architecture
appropriately.

I'm not sure what we can expect to see in the <architecture> tag, so
I'm only doing this for x86_64 right now where I've seen "i386:x86_64"
used.  I've seen a target.xml from a jtag board that sends just "arm"
because it doesn't know more specifically what type of board it is
connected to...  

<rdar://problem/29908970> 

llvm-svn: 322339
2018-01-12 01:16:13 +00:00
Jason Molenda aae5b69079 Change uses of strncpy in debugserver to strlcpy
for better safety.

<rdar://problem/32906923> 

llvm-svn: 320242
2017-12-09 03:37:09 +00:00
Vedant Kumar 07d956149b Fix misc -Wcast-qual warnings, NFC
llvm-svn: 319937
2017-12-06 19:21:11 +00:00
Vedant Kumar 606908aab5 Remove no-op function pointer null checks, NFC
Null-checking functions which aren't marked weak_import is a no-op
(the compiler rewrites the check to 'true'), regardless of whether a
library providing its definition is weak-linked. If the deployment
target is greater than the minimum requirement, the availability markup
on APIs does not lower to weak_import.

Remove no-op null checks to clean up the code and silence warnings.

Differential Revision: https://reviews.llvm.org/D40812

llvm-svn: 319936
2017-12-06 19:21:10 +00:00
Jason Molenda d2d4c8db45 Update default cpu subtype for armv7 processes to armv7k, the most
likely cpu subtype at this point.

llvm-svn: 306752
2017-06-29 22:50:53 +00:00
Zachary Turner 97206d5727 Rename Error -> Status.
This renames the LLDB error class to Status, as discussed
on the lldb-dev mailing list.

A change of this magnitude cannot easily be done without
find and replace, but that has potential to catch unwanted
occurrences of common strings such as "Error".  Every effort
was made to find all the obvious things such as the word "Error"
appearing in a string, etc, but it's possible there are still
some lingering occurences left around.  Hopefully nothing too
serious.

llvm-svn: 302872
2017-05-12 04:51:55 +00:00
Jason Molenda 11506a9d1c Correct the names of some target conditional defines in debugserver.
llvm-svn: 301034
2017-04-21 20:19:28 +00:00
Jason Molenda 3ca38564cb Fix the last commit; compression was being enabled on mac native
which led to

ERROR: test_auxv_chunked_reads_work_debugserver (tools/lldb-server/TestGdbRemoteAuxvSupport.py)
ERROR: test_auxv_data_is_correct_size_debugserver (tools/lldb-server/TestGdbRemoteAuxvSupport.py)
ERROR: test_auxv_keys_look_valid_debugserver (tools/lldb-server/TestGdbRemoteAuxvSupport.py)
ERROR: test_qSupported_returns_known_stub_features_debugserver (tools/lldb-server/TestLldbGdbServer.py)

failures because debugserver was advertising compression being available, e.g.

send packet: $qSupported:xmlRegisters=i386,arm,mips#12
read packet: $qXfer:features:read+;PacketSize=20000;qEcho+;SupportedCompressions=zlib-deflate;DefaultCompressionMinSize=384#00

maybe these tests should be a little more accepting of additional
features.  but I didn't mean for this to be enabled on mac native.

llvm-svn: 292890
2017-01-24 06:09:06 +00:00
Jason Molenda 5a6826ebc4 Enable compression capability in debugserver for all of ios/watchos/tvos
environments.

<rdar://problem/30159019> 

llvm-svn: 292882
2017-01-24 04:43:40 +00:00
Pavel Labath 72090c2162 Move StdStringExtractor to tools/debugserver
The class is only used in the debugserver. The rest of lldb has the StringExtractor class.

Xcode project will need to be updated after this.

llvm-svn: 281226
2016-09-12 16:13:05 +00:00
Kate Stone b9c1b51e45 *** This commit represents a complete reformatting of the LLDB source code
*** 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
2016-09-06 20:57:50 +00:00
Zachary Turner 44c35e80b1 Copy StringExtractor to StdStringExtractor.
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
2016-08-29 19:45:59 +00:00
Todd Fiala 759300192a Add StructuredData plugin type; showcase with new DarwinLog feature
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
2016-08-19 04:21:48 +00:00
Todd Fiala a07e4a8352 Revert "Add StructuredData plugin type; showcase with new DarwinLog feature"
This reverts commit 1d885845d1451e7b232f53fba2e36be67aadabd8.

llvm-svn: 279200
2016-08-19 03:03:58 +00:00
Todd Fiala aef7de8492 Add StructuredData plugin type; showcase with new DarwinLog feature
See docs/structured_data/StructuredDataPlugins.md for details.

differential review: https://reviews.llvm.org/D22976

reviewers: clayborg, jingham
llvm-svn: 279198
2016-08-19 02:52:07 +00:00
Todd Fiala abd6186216 Undo usage of LLVM macros in debugserver
We don't take a dependency on LLVM in debugserver.
This was failing to compile before.

llvm-svn: 278190
2016-08-10 00:53:21 +00:00
Zachary Turner f343968f5d Delete Host/windows/win32.h
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
2016-08-09 23:06:08 +00:00
Jason Molenda a2992311a2 Add support to debugserver for some new ways to interact with dyld
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
2016-07-07 01:09:23 +00:00
Saleem Abdulrasool d97dd11f2f debugserver; fix -Wunused-local-typedef, -Wunused-variable warnings
Remove the typedef and local structure which was unused.  Fixes last of the new
clang warnings in the debugserver build.  NFC.

llvm-svn: 268759
2016-05-06 17:33:13 +00:00
Saleem Abdulrasool 247731d4d3 debugserver: fix a couple of -Wmissing-field-initializers warnings
Explicitly provide an initializer for the std::vector in the constructed type.
Addresses -Wmissing-field-initializers warnings from clang.  NFC.

llvm-svn: 268758
2016-05-06 17:33:09 +00:00
Saleem Abdulrasool 4533f7b6e8 debugserver: fix some -Wpessimizing-move warnings
Remove the unnecessary use of std::move to permit the compiler to perform NVRO
instead.  Fixes more warnings from clang.  NFC.

llvm-svn: 268757
2016-05-06 17:33:04 +00:00
Saleem Abdulrasool 2bb818880b debugserver: fix a few -Wcovered-swift-default warnings
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
2016-05-06 17:33:01 +00:00
Greg Clayton 830c81d511 Fixed an issue that could cause debugserver to return two stop reply packets ($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
2016-04-01 00:41:29 +00:00
Greg Clayton 17499dde46 A while back in revison 244716 we added support for getting the host OS 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
2016-01-28 00:16:11 +00:00
Sean Callanan 10badfc924 Fixed some #ifdefs. We were erroneously not supporting certain simulators.
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
2016-01-20 23:12:39 +00:00
Jason Molenda 77f8935218 Changes to lldb and debugserver to reduce extraneous memory reads
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
2016-01-12 07:09:16 +00:00
Jason Molenda 0c015c6279 In the questionmark packet ("T"), print the "threads:" and "thread-pcs:"
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
2016-01-08 23:16:03 +00:00
Jason Molenda 26d84e8097 Change the key name for the libdispatch queue serial number from
"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
2016-01-08 00:20:48 +00:00
Jason Molenda 7e9bd599a2 Add a new "thread-pcs" key-value pair to the T packet response from
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
2015-12-15 23:47:44 +00:00
Jason Molenda 0071be6590 When supplying memory to expedite the unwinds in the T packet,
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
2015-12-12 01:32:09 +00:00
Dawn Perchik e3f250dbda [debugserver] Fix OSX build for older XCode versions after r251091.
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
2015-10-24 01:31:12 +00:00
Dawn Perchik 51ac8a0e17 [debugserver] Fix indentation in RNBRemote.cpp.
llvm-svn: 251169
2015-10-24 01:24:00 +00:00
Jason Molenda b9d5459d5a Remove some tabs that snuck into debugserver-entitlements.plist, etc.
llvm-svn: 251092
2015-10-23 02:54:21 +00:00
Jason Molenda c611a74059 Upstreaming the apple internal changes that accumulated during the
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
2015-10-23 02:49:51 +00:00
Bruce Mitchener adb99821bc Fix typos.
Summary: Another round of minor typo fixes.

Reviewers: clayborg

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D13026

llvm-svn: 248243
2015-09-22 05:07:56 +00:00
Jason Molenda 9878e3b4b5 A partner to the cleanup in r247741, change the variables names in
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
2015-09-15 23:49:57 +00:00
Jason Molenda 63bd0db071 Clean up register naming conventions inside lldb.
"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
2015-09-15 23:20:34 +00:00
Jason Molenda 6acc86c3f5 Have debugserver send the OS version string plus
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
2015-08-12 03:27:33 +00:00
Dawn Perchik 3cb6dd6e94 Fix build of lldb on Mavericks after svn rev.243511.
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
2015-07-31 00:26:46 +00:00
Jason Molenda 752e1e833b When debugserver fails to attach to a process on a Darwin
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
2015-07-29 01:42:16 +00:00
Jason Molenda 5d935e8d24 Fix the variable used to reply to the qGDBServerVersion
packet so that debugserver will send a reply like

name:debugserver;version:340.99;

<rdar://problem/21933963> 

llvm-svn: 242968
2015-07-22 23:42:54 +00:00
Bruce Mitchener a026de0585 Fix warnings.
Reviewers: clayborg

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D11404

llvm-svn: 242913
2015-07-22 17:31:44 +00:00
Greg Clayton 2e309076f2 More packet performance improvements.
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
2015-07-17 23:42:28 +00:00
Jason Molenda d25d72fb79 Only include the stack memory for the caller stack
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
2015-07-16 03:42:40 +00:00