Change the scanning algorithm in DynamicLoaderDarwinKernel::SearchForKernelNearPC.

Currently when lldb might be doing a kernel debug session, it scans through
memory by taking the current pc value and looking for a kernel at megabyte
boundaries, up to 32MB behind $pc.  This adjusts the algorithm to
scan back at every 16k page boundary and to stop scanning as soon
as we hit a memory read error.  The addition of stopping at a memory read
error saves us from tons of unnecessary packet traffic on generic 
targets where lldb might look for a kernel binary.

I've been trying to think of how to construct a test for this; it's a bit
tricky.  A gdb-remote protocol test with the contents of a fake tiny kernel
mach-o binary would satisify part of it, but this kernel path also directly
calls over to dsymForUUID or DebugSymbols framework lookups to find the 
kernel binary as well.  I'll keep thinking about this one, but it's so
intertangled with these two external systems that it may be hard to do.

<rdar://problem/48578197> 

llvm-svn: 355476

0 files changed, 0 insertions, 0 deletions