[rfa] mips heuristic_proc_start fix

[Daniel Jacobowitz <dmj+@andrew.cmu.edu>]

This one was fun to track down... I've been getting corrupt PC values off
the stack in backtraces, something which needs to be fixed elsewhere.  The
interesting thing is that the PC I was reading was 0x2.  Remember that
CORE_ADDR on MIPS is an unsigned 64-bit quantity.

There's some wrapping bugs here.  If start_pc - heuristic_fence_post wraps,
it may be greater than VM_MIN_ADDRESS, but it will also be greater than
start_pc, so we will fail - not ideal, maybe, but safe.  On the other hand,
if start_pc == 0x2, and heuristic_fence_post == 0, then fence gets set to
VM_MIN_ADDRESS (0x400000 here).  start_pc -= instlen is 0xfffffffffffffffe. 
That's above the fencepost!  Oops.

OK to commit?

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

2001-07-06  Daniel Jacobowitz  <drow@mvista.com>

	* mips-tdep.c (heuristic_proc_start):  Avoid long loop if start_pc
	is corrupt.

Index: mips-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/mips-tdep.c,v
retrieving revision 1.56
diff -u -r1.56 mips-tdep.c
--- mips-tdep.c	2001/07/06 05:35:17	1.56
+++ mips-tdep.c	2001/07/06 18:03:57
@@ -1506,6 +1506,13 @@
       || fence < VM_MIN_ADDRESS)
     fence = VM_MIN_ADDRESS;
 
+  if (start_pc < fence)
+    {
+      warning ("Warning: GDB can't find the start of the function at 0x%s (wraparound).",
+	       paddr_nz (pc));
+      return 0;
+    }
+
   instlen = pc_is_mips16 (pc) ? MIPS16_INSTLEN : MIPS_INSTLEN;
 
   /* search back for previous return */