When unwinding from the first frame, try to ask the remote debugserver

if this is a mapped/executable region of memory.  If it isn't, we've jumped
through a bad pointer and we know how to unwind the stack correctly based
on the ABI.  

Previously I had 0x0 special cased but if you jumped to 0x2 on x86_64 one
frame would be skipped because the unwinder would try using the x86_64 
ArchDefaultUnwindPlan which relied on the rbp.

Fixes <rdar://problem/10508291>

llvm-svn: 146477

1 files changed, 12 insertions, 0 deletions

diff --git a/lldb/docs/lldb-gdb-remote.txt b/lldb/docs/lldb-gdb-remote.txt
index 381d720164e..bfede67df70 100644
--- a/lldb/docs/lldb-gdb-remote.txt
+++ b/lldb/docs/lldb-gdb-remote.txt
@@ -592,6 +592,18 @@ tuples tp return are:
                                      // a hex encoded string value that 
                                      // contains an error string
                                     
+If the address requested is not in a mapped region (e.g. we've jumped through
+a NULL pointer and are at 0x0) currently lldb expects to get back the size 
+of the unmapped region -- that is, the distance to the next valid region.
+For instance, with a Mac OS X process which has nothing mapped in the first
+4GB of its address space, if we're asking about address 0x2,
+
+  qMemoryRegionInfo:2
+  start:2;size:fffffffe;
+
+The lack of 'permissions:' indicates that none of read/write/execute are valid
+for this region.
+
 //----------------------------------------------------------------------
 // Stop reply packet extensions
 //