This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64.
(More architectures coming soon).
Not every debugserver option is covered yet. Currently
the lldb-gdbserver command line can start unattached,
start attached to a pid (process-name attach not supported yet),
or accept lldb attaching and launching a process or connecting
by process id.
The history of this large change can be found here:
https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64
Until mid/late April, I was not sharing the work and continued
to rebase it off of head (developed via id tfiala@google.com). I switched over to
user todd.fiala@gmail.com in the middle, and once I went to github, I did
merges rather than rebasing so I could share with others.
llvm-svn: 212069
lldb support. I'll be doing more testing & cleanup but I wanted to
get the initial checkin done.
This adds a new SBExpressionOptions::SetLanguage API for selecting a
language of an expression.
I added adds a new SBThread::GetInfoItemByPathString for retriving
information about a thread from that thread's StructuredData.
I added a new StructuredData class for representing
key-value/array/dictionary information (e.g. JSON formatted data).
Helper functions to read JSON and create a StructuredData object,
and to print a StructuredData object in JSON format are included.
A few Cocoa / Cocoa Touch data formatters were updated by Enrico
to track changes in iOS 8 / Yosemite.
Before we query a thread's extended information, the system runtime may
provide hints to the remote debug stub that it will use to retrieve values
out of runtime structures. I added a new SystemRuntime method
AddThreadExtendedInfoPacketHints which allows the SystemRuntime to add
key-value type data to the initial request that we send to the remote stub.
The thread-format formatter string can now retrieve values out of a thread's
extended info structured data. The default thread-format string picks up
two of these - thread.info.activity.name and thread.info.trace_messages.
I added a new "jThreadExtendedInfo" packet in debugserver; I will
add documentation to the lldb-gdb-remote.txt doc soon. It accepts
JSON formatted arguments (most importantly, "thread":threadnum) and
it returns a variety of information regarding the thread to lldb
in JSON format. This JSON return is scanned into a StructuredData
object that is associated with the thread; UI layers can query the
thread's StructuredData to see if key-values are present, and if
so, show them to the user. These key-values are likely to be
specific to different targets with some commonality among many
targets. For instance, many targets will be able to advertise the
pthread_t value for a thread.
I added an initial rough cut of "thread info" command which will print
the information about a thread from the jThreadExtendedInfo result.
I need to do more work to make this format reasonably.
Han Ming added calls into the pmenergy and pmsample libraries if
debugserver is run on Mac OS X Yosemite to get information about the
inferior's power use.
I added support to debugserver for gathering the Genealogy information
about threads, if it exists, and returning it in the jThreadExtendedInfo
JSON result.
llvm-svn: 210874
debugserver now returns $X09 as the immediate response to
a $k kill process request rather than $W09.
ProcessGDBRemote now properly handles X as indication of
a process exit state.
The @debugserver_test and @lldb_test for $k now properly expects
an X notification (signal-caused exit) after killing a just-attached
inferior that was still in the stopped state.
llvm-svn: 209108
data if it is available.
Change ProcessGDBRemote's maximum read/write packet size from a
fixed 512 byte value to asking the remote gdb stub what its maximum
is, using up to 128kbyte sizes if that's allowed, and falling back
to 512 if the remote gdb stub doesn't advertise a max packet size.
Add a new "process plugin packet xfer-size" command that can be used
to override the maximum packet size (although not exceeding any packet
size maximum published by the remote gdb stub).
<rdar://problem/16032150>
llvm-svn: 208058
This is a purely mechanical change explicitly casting any parameters for printf
style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux.
llvm-svn: 205607
These changes were written by Greg Clayton, Jim Ingham, Jason Molenda.
It builds cleanly against TOT llvm with xcodebuild. I updated the
cmake files by visual inspection but did not try a build. I haven't
built these sources on any non-Mac platforms - I don't think this
patch adds any code that requires darwin, but please let me know if
I missed something.
In debugserver, MachProcess.cpp and MachTask.cpp were renamed to
MachProcess.mm and MachTask.mm as they picked up some new Objective-C
code needed to launch processes when running on iOS.
llvm-svn: 205113
(lldb) b puts
(lldb) expr -g -i0 -- (int)puts("hello")
First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression.
Main features:
- New ObjectFileJIT class that can be easily created for JIT functions
- debug info can now be enabled when parsing expressions
- source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit
- "expr -g --" allows you to single step through your expression function with source code
<rdar://problem/16382881>
llvm-svn: 204682
This is a mechanical cleanup of unused functions. In the case where the
functions are referenced (in comment form), I've simply commented out the
functions. A second pass to clean that up is warranted.
The functions which are otherwise unused have been removed. Some of these were
introduced in the initial commit and not in use prior to that point!
NFC
llvm-svn: 204310
ProcessGDBRemote::GetAuxvData obtains the auxv from a remote gdbserver (via a binary-data packet), and returns the data as a DataBufferSP.
The patch includes a small fix to GDBRemoteCommunicationClient::SendPacketsAndConcatenateResponses() to support binary file format packet returns (by not assuming each binary packet is a null-terminated string when concatenating them).
llvm-svn: 202907
The many many benefits include:
1 - Input/Output/Error streams are now handled as real streams not a push style input
2 - auto completion in python embedded interpreter
3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use
4 - it is now possible to use curses to drive LLDB (please try the "gui" command)
We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases.
llvm-svn: 200263
This change fixes a bug recently introduced in ProcessGDBRemote that
prevented the Python register definition file from getting loaded when
the qRegisterInfo0 response returned $00#.
Patch by Steve Pucci.
llvm-svn: 198742
it needs to fall back to using the HostArchitecture if a valid one is not
returned. When doing low-level system debugging we may not have a process
(or the remote stub may not support the qProcessInfo packet) in which case
we should fall back to the architecture we determined via qHostInfo.
<rdar://problem/15713180>
llvm-svn: 197857
<rdar://problem/15600045>
Due to other recent changes, all connections to GDB servers that didn't support the "QStartNoAckMode" packet would cause us to fail to attach to the remote GDB server.
The problem was that SendPacket* and WaitForResponse* packets would return a size_t indicating the number of bytes sent/received. The other issue was WaitForResponse* packets would strip the leading '$' and the trailing "#CC" (checksum) bytes, so the unimplemented response packet of "$#00" would get stripped and the WaitForResponse* packets would return 0.
These new error codes give us flexibility to to more intelligent things in response to what is returned.
llvm-svn: 196610
This gets rid of our hacky "get_random_port()" which would grab a random port and tell debugserver to open that port. Now LLDB creates, binds, listens and accepts a connection by binding to port zero and sending the correctly bound port down as the host:port to connect back to.
Fixed the "ConnectionFileDescriptor" to be able to correctly listen for connections from a specified host, localhost, or any host. Prior to this fix "listen://" only accepted the following format:
listen://<port>
But now it can accept:
listen://<port> // Listen for connection from localhost on port <port>
listen://<host>:<port> // Listen for connection from <host> and <port>
listen://*:<port> // Listen for connection from any host on port <port>
llvm-svn: 196547
This helps ensure that the launched debugserver is ready and listening for a connection. Prior to this we had a race condition.
Consolidate the launching of debugserver into a single place: a static function in GDBRemoteCommunication.
llvm-svn: 196401
Improved the detection of a valid GDB server where we actually can connect to a socket, but then it doesn't read or write anything (which happens with some USB mux software).
Host::MakeDirectory() now can make as many intermediate directories as needed.
The testsuite now has very initial support for remote test suite running. When running on a remote platform, the setUp function for the test will make a new directory and select it as the working directory on the remote host.
Added a common function that can be used to create the short option string for getopt_long calls.
llvm-svn: 195541
Example code:
remote_platform = lldb.SBPlatform("remote-macosx");
remote_platform.SetWorkingDirectory("/private/tmp")
debugger.SetSelectedPlatform(remote_platform)
connect_options = lldb.SBPlatformConnectOptions("connect://localhost:1111");
err = remote_platform.ConnectRemote(connect_options)
if err.Success():
print >> result, 'Connected to remote platform:'
print >> result, 'hostname: %s' % (remote_platform.GetHostname())
src = lldb.SBFileSpec("/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework", False)
dst = lldb.SBFileSpec()
# copy src to platform working directory since "dst" is empty
err = remote_platform.Install(src, dst);
if err.Success():
print >> result, '%s installed successfully' % (src)
else:
print >> result, 'error: failed to install "%s": %s' % (src, err)
Implemented many calls needed in lldb-platform to be able to install a directory that contains symlinks, file and directories.
The remote lldb-platform can now launch GDB servers on the remote system so that remote debugging can be spawned through the remote platform when connected to a remote platform.
The API in SBPlatform is subject to change and will be getting many new functions.
llvm-svn: 195273
Added a new key that we understand for the "qHostInfo" packet: "default_packet_timeout:T;" where T is a default packet timeout in seconds.
This allows GDB servers with known slow packet response times to increase the default timeout to a value that makes sense for the connection.
llvm-svn: 193425
This commit adds an example python file that can be used with 'target-definition-file' setting for Linux gdbserver.
This file has an extra key 'breakpoint-pc-offset' that LLDB uses to determine how much to change the PC
after hitting the breakpoint.
llvm-svn: 192962
queue name out of ProcessGDBRemote and in to the Platform
plugin, specifically PlatformDarwin.
Also add a Platform method to translate a dispatch_quaddr
to a QueueID, and a Thread::GetQueueID().
I'll add an SBThread::GetQueueID() next.
llvm-svn: 192949
- Made the dynamic register context for the GDB remote plug-in inherit from the generic DynamicRegisterInfo to avoid code duplication
- Finished up the target definition python setting stuff.
- Added a new "slice" key/value pair that can specify that a register is part of another register:
{ 'name':'eax', 'set':0, 'bitsize':32, 'encoding':eEncodingUint, 'format':eFormatHex, 'slice': 'rax[31:0]' },
- Added a new "composite" key/value pair that can specify that a register is made up of two or more registers:
{ 'name':'d0', 'set':0, 'bitsize':64 , 'encoding':eEncodingIEEE754, 'format':eFormatFloat, 'composite': ['s1', 's0'] },
- Added a new "invalidate-regs" key/value pair for when a register is modified, it can invalidate other registers:
{ 'name':'cpsr', 'set':0, 'bitsize':32 , 'encoding':eEncodingUint, 'format':eFormatHex, 'invalidate-regs': ['r8', 'r9', 'r10', 'r11', 'r12', 'r13', 'r14', 'r15']},
This now completes the feature that allows a GDB remote target to completely describe itself.
llvm-svn: 192858
When debugging with the GDB remote in LLDB, LLDB uses special packets to discover the
registers on the remote server. When those packets aren't supported, LLDB doesn't
know what the registers look like. This checkin implements a setting that can be used
to specify a python file that contains the registers definitions. The setting is:
(lldb) settings set plugin.process.gdb-remote.target-definition-file /path/to/module.py
Inside module there should be a function:
def get_dynamic_setting(target, setting_name):
This dynamic setting function is handed the "target" which is a SBTarget, and the
"setting_name", which is the name of the dynamic setting to retrieve. For the GDB
remote target definition the setting name is 'gdb-server-target-definition'. The
return value is a dictionary that follows the same format as the OperatingSystem
plugins follow. I have checked in an example file that implements the x86_64 GDB
register set for people to see:
examples/python/x86_64_target_definition.py
This allows LLDB to debug to any archticture that is support and allows users to
define the registers contexts when the discovery packets (qRegisterInfo, qHostInfo)
are not supported by the remote GDB server.
A few benefits of doing this in Python:
1 - The dynamic register context was already supported in the OperatingSystem plug-in
2 - Register contexts can use all of the LLDB enumerations and definitions for things
like lldb::Format, lldb::Encoding, generic register numbers, invalid registers
numbers, etc.
3 - The code that generates the register context can use the program to calculate the
register context contents (like offsets, register numbers, and more)
4 - True dynamic detection could be used where variables and types could be read from
the target program itself in order to determine which registers are available since
the target is passed into the python function.
This is designed to be used instead of XML since it is more dynamic and code flow and
functions can be used to make the dictionary.
llvm-svn: 192646
Added a way to set hardware breakpoints from the "breakpoint set" command with the new "--hardware" option. Hardware breakpoints are not a request, they currently are a requirement. So when breakpoints are specified as hardware breakpoints, they might fail to be set when they are able to be resolved and should be used sparingly. This is currently hooked up for GDB remote debugging.
Linux and FreeBSD should quickly enable this feature if possible, or return an error for any breakpoints that are hardware breakpoint sites in the "virtual Error Process::EnableBreakpointSite (BreakpointSite *bp_site);" function.
llvm-svn: 192491
Added a setting to control timeout for kdp response packets. While I was at it, I also added a way to control the response timeout for gdb-remote packets.
KDP defaults to 5 seconds, and GDB defaults to 1 second. These were the default values that were in the code prior to adding these settings.
(lldb) settings set plugin.process.gdb-remote.packet-timeout 10
(lldb) settings set plugin.process.kdp-remote.packet-timeout 10
llvm-svn: 186360
names when specifying the DynamicLoaderDarwinKernel.
ProcessGDBRemote wasn't setting the dyld string any more; remove
the remaining code tracking the dyld plugin name altogether from
that process plugin.
llvm-svn: 181658
<rdar://problem/13594769>
Main changes in this patch include:
- cleanup plug-in interface and use ConstStrings for plug-in names
- Modfiied the BSD Archive plug-in to be able to pick out the correct .o file when .a files contain multiple .o files with the same name by using the timestamp
- Modified SymbolFileDWARFDebugMap to properly verify the timestamp on .o files it loads to ensure we don't load updated .o files and cause problems when debugging
The plug-in interface changes:
Modified the lldb_private::PluginInterface class that all plug-ins inherit from:
Changed:
virtual const char * GetPluginName() = 0;
To:
virtual ConstString GetPluginName() = 0;
Removed:
virtual const char * GetShortPluginName() = 0;
- Fixed up all plug-in to adhere to the new interface and to return lldb_private::ConstString values for the plug-in names.
- Fixed all plug-ins to return simple names with no prefixes. Some plug-ins had prefixes and most ones didn't, so now they all don't have prefixed names, just simple names like "linux", "gdb-remote", etc.
llvm-svn: 181631
namespace lldb_private {
class Thread
{
virtual lldb::StopInfoSP
GetPrivateStopReason() = 0;
};
}
To not be virtual. The lldb_private::Thread now handles the correct caching and will call a new pure virtual function:
namespace lldb_private {
class Thread
{
virtual bool
CalculateStopInfo() = 0;
}
}
This function must be overridden by thead lldb_private::Thread subclass and the only thing it needs to do is to set the Thread::StopInfo() with the current stop reason and return true, or return false if there is no stop reason. The lldb_private::Thread class will take care of calling this function only when it is required. This allows lldb_private::Thread subclasses to be a bit simpler and not all need to duplicate the cache and invalidation settings.
Also renamed:
lldb::StopInfoSP
lldb_private::Thread::GetPrivateStopReason();
To:
lldb::StopInfoSP
lldb_private::Thread::GetPrivateStopInfo();
Also cleaned up a case where the ThreadPlanStepOverBreakpoint might not re-set its breakpoint if the thread disappears (which was happening due to a bug when using the OperatingSystem plug-ins with memory threads and real threads).
llvm-svn: 181501
while we develop a better understanding of how to manage the thread lists in a platform-independant fashion.
Reviewed by: Daniel Malea
llvm-svn: 181323
This checkin aims to fix this. The process now has two thread lists: a real thread list for threads that are created by the lldb_private::Process subclass, and the user visible threads. The user visible threads are the same as the real threas when no OS plug-in in used. But when an OS plug-in is used, the user thread can be a combination of real and "memory" threads. Real threads can be placed inside of memory threads so that a thread appears to be different, but is still controlled by the actual real thread. When the thread list needs updating, the lldb_private::Process class will call the: lldb_private::Process::UpdateThreadList() function with the old real thread list, and the function is expected to fill in the new real thread list with the current state of the process. After this function, the process will check if there is an OS plug-in being used, and if so, it will give the old user thread list, the new real thread list and the OS plug-in will create the new user thread list from both of these lists. If there is no OS plug-in, the real thread list is the user thread list.
These changes keep the lldb_private::Process subclasses clean and no changes are required.
llvm-svn: 181091
<rdar://problem/13723772>
Modified the lldb_private::Thread to work much better with the OperatingSystem plug-ins. Operating system plug-ins can now return have a "core" key/value pair in each thread dictionary for the OperatingSystemPython plug-ins which allows the core threads to be contained with memory threads. It also allows these memory threads to be stepped, resumed, and controlled just as if they were the actual backing threads themselves.
A few things are introduced:
- lldb_private::Thread now has a GetProtocolID() method which returns the thread protocol ID for a given thread. The protocol ID (Thread::GetProtocolID()) is usually the same as the thread id (Thread::GetID()), but it can differ when a memory thread has its own id, but is backed by an actual API thread.
- Cleaned up the Thread::WillResume() code to do the mandatory parts in Thread::ShouldResume(), and let the thread subclasses override the Thread::WillResume() which is now just a notification.
- Cleaned up ClearStackFrames() implementations so that fewer thread subclasses needed to override them
- Changed the POSIXThread class a bit since it overrode Thread::WillResume(). It is doing the wrong thing by calling "Thread::SetResumeState()" on its own, this shouldn't be done by thread subclasses, but the current code might rely on it so I left it in with a TODO comment with an explanation.
llvm-svn: 180886
Fixed the GDB remote with the python OS plug-in to not show core threads when they aren't desired and also to have the threads "to the right thing" when continuing.
llvm-svn: 179912
LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.
All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down.
llvm-svn: 178191
to have it not named appropriately. Also in StopInfoMachException, we aren't testing for software or not software, just
whether the thing is a breakpoint we set. So don't use "software"...
llvm-svn: 175241
Enhance lldb so it can search for a kernel in memory when attaching
to a remote system. Remove some of the code that was doing this
from ProcessMachCore and ProcessGDBRemote and put it in
DynamicLoaderDarwinKernel.
I've added a new setting, plugin.dynamic-loader.darwin-kernel.scan-type
which can be set to
none - for environments where reading random memory can cause a
device crash
basic - look at one fixed location in memory for a kernel load address,
plus the contents of that address
fast-scan - the default, tries "basic" and then looks for the kernel's
mach header near the current pc value when lldb connects
exhaustive-scan - on 32-bit targets, step through the entire range where
the kernel can be loaded, looking for the kernel binary
I don't have the setting set up correctly right now, I'm getting back unexpected
values from the Property system, but I'll figure that out tomorrow and fix.
Besides that, all of the different communication methods / types of kernels
appear to be working correctly with these changes.
llvm-svn: 173891
Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.
So I defined a new "lldb::offset_t" which should be used for all file offsets.
After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.
Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.
llvm-svn: 173463
Fixed the 32, 16, and 8 bit pseudo regs for x86_64 (real reg of "rax" which subvalues "eax", "ax", etc...) to correctly get updated when stepping. Also fixed it so actual registers can specify what other registers must be invalidated when a register is modified. Previously, only pseudo registers could invalidate other registers.
Modified the LLDB qRegisterInfo extension to the GDB remote interface to support specifying the containing registers with the new "container-regs" key whose value is a comma separated list of register numbers. Also added a "invalidate-regs" key whose value is also a comma separated list of register numbers.
Removed the hack GDBRemoteDynamicRegisterInfo::Addx86_64ConvenienceRegisters() function and modified "debugserver" to specify the registers correctly using the new "container-regs" and "invalidate-regs" keys.
llvm-svn: 173096
Swap in index ids for thread ids in GDBRemoteCommunicationClient. Besides dealing with the async logic, I have to take care of the situation when the inferior paused as well.
llvm-svn: 172869
Update the debugserver "qProcessInfo" implementation to return the
cpu type, cpu subtype, OS and vendor information just like qHostInfo
does so lldb can create an ArchSpec based on the returned values.
Add a new GetProcessArchitecture to GDBRemoteCommunicationClient akin
to GetHostArchitecture. If the qProcessInfo packet is supported,
GetProcessArchitecture will return the cpu type / subtype of the
process -- e.g. a 32-bit user process running on a 64-bit x86_64 Mac
system.
Have ProcessGDBRemote set the Target's architecture based on the
GetProcessArchitecture when we've completed an attach/launch/connect.
llvm-svn: 170491
I modified the "Args::StringtoAddress(...)" function to be able to evaluate address expressions. This is now used for any command line arguments or options that takes addresses like:
memory read <addr> [<end-addr>]
memory write <addr>
breakpoint set --address <addr>
disassemble --start-address <addr> --end-address <addr>
It calls the expression parser to evaluate the address expression and will also work around the issue where the compiler doesn't like to add offsets to function pointers (which is what happens when you try to evaluate "main + 12"). So there is a temp fix in the Args::StringtoAddress() to work around this until we can get special compiler support for debug expressions with function pointers.
llvm-svn: 169556
- add new header lldb-python.h to be included before other system headers
- short term fix (eventually python dependencies must be cleaned up)
Patch by Matt Kopec!
llvm-svn: 169341
GCD queue names of threads to
ProcessGDBRemote::GetDispatchQueueNameForThread()
May need tweaking once this version is rolled out but visual
inspection looks fine.
<rdar://problem/12333100>
llvm-svn: 167667
Added commands to the KDP plug-in that allow sending raw commands through the KDP protocol. You specify a command byte and a payload as ASCII hex bytes, and the packet is created with a valid header/sequenceID/length and sent. The command responds with a raw ASCII hex string that contains all bytes in the reply including the header.
An example of sending a read register packet for the GPR on x86_64:
(lldb) process plugin packet send --command 0x07 --payload 0100000004000000
llvm-svn: 166346
I added the ability for a process plug-in to implement custom commands. All the lldb_private::Process plug-in has to do is override:
virtual CommandObject *
GetPluginCommandObject();
This object returned should be a multi-word command that vends LLDB commands. There is a sample implementation in ProcessGDBRemote that is hollowed out. It is intended to be used for sending a custom packet, though the body of the command execute function has yet to be implemented!
llvm-svn: 165861
Then make the Thread a Broadcaster, and get it to broadcast when the selected frame is changed (but only from the Command Line) and when Thread::ReturnFromFrame
changes the stack.
Made the Driver use this notification to print the new thread status rather than doing it in the command.
Fixed a few places where people were setting their broadcaster class by hand rather than using the static broadcaster class call.
<rdar://problem/12383087>
llvm-svn: 165640
if we have a kernel binary, set the target's architecture to match.
Include the target's architecture in the ModuleSpec when we're searching for the
kext binaries on the local system -- otherwise we won't get a specific slice of
a fat file picked out for us and we won't use the returned Module correctly.
Remove the redundant attempt to find a file on the local filesystem from this method.
In ProcessGDBRemote::CheckForKernel(), if we have a kernel binary in memory, mark
the canJIT as false. There is no jitting code in kernel debug sessions.
llvm-svn: 165357
remove the duplicates of this code in ProcessGDBRemote and ProcessKDP.
These two Process plugins will hardcode their DynamicLoader name to be
the DynamicLoaderDarwinKernel so the correct DynamicLoader is picked,
and return the kernel load address as the ImageInfosAddress.
<rdar://problem/12417038>
llvm-svn: 165080
When attaching to a remote system that does not look like a typical vendor system, and no
executable binary was specified to lldb, check a couple of fixed locations where kernels
running in ASLR mode (slid in memory to a random address) store their load addr when booted
in debug mode, and relocate the symbols or load the kernel wholesale from the host computer
if we can find it.
<rdar://problem/7714201>
llvm-svn: 164888
loaded at a random offset).
To get the kernel's UUID and load address I need to send a kdp
packet so I had to implement the kernel relocation (and attempt to
find the kernel if none was provided to lldb already) in ProcessKDP
-- but this code really properly belongs in DynamicLoaderDarwinKernel.
I also had to add an optional Stream to ConnectRemote so
ProcessKDP::DoConnectRemote can print feedback about the remote kernel's
UUID, load address, and notify the user if we auto-loaded the kernel via
the UUID.
<rdar://problem/7714201>
llvm-svn: 164881
