From mboxrd@z Thu Jan 1 00:00:00 1970 From: Daniel Jacobowitz To: gdb-patches@sources.redhat.com Subject: [rfa] mips heuristic_proc_start fix Date: Fri, 06 Jul 2001 11:20:00 -0000 Message-id: <20010706112010.A5578@nevyn.them.org> X-SW-Source: 2001-07/msg00155.html 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 * 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 */