<rdar://problem/12491235>
authorJason Molenda <jmolenda@apple.com>
Wed, 30 Jan 2013 04:39:32 +0000 (04:39 +0000)
committerJason Molenda <jmolenda@apple.com>
Wed, 30 Jan 2013 04:39:32 +0000 (04:39 +0000)
commit6ba6d3d1790bf6615e8ea867ea9ff6947bda63a3
treefd91e72f96ac098b78dcec1127cc60d29494aeb8
parent26127bd746144842e245e7ecaa734a0219c34dbc
<rdar://problem/12491235>

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
lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.cpp
lldb/source/Plugins/DynamicLoader/Darwin-Kernel/DynamicLoaderDarwinKernel.h
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.h
lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp