This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
[rfa] mips heuristic_proc_start fix
- To: gdb-patches at sources dot redhat dot com
- Subject: [rfa] mips heuristic_proc_start fix
- From: Daniel Jacobowitz <dmj+ at andrew dot cmu dot edu>
- Date: Fri, 6 Jul 2001 11:20:10 -0700
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 */