[RFC] Modernize HP-UX core file handling

[RFC] Modernize HP-UX core file handling

[Mark Kettenis]

This patch modernizes the way we read HP-UX core files.  This patch is
necessary to make a inf-ttrace.c based HP-UX debugger read core files
again.  I've tested this on 32-it HP-UX 11.00, but not on a 64-bit
system.  The code should be able to read 64-bit core files, but it
really should be tested.  Randolph/Joel, can one of you test whether
reading core files still works after applying this patch?

Once this is in, I'll switch 32-bit HP-UX 11.x over to the new
inf-ttrace.c stuff.

Mark


Index: ChangeLog
from  Mark Kettenis  <kettenis@gnu.org>

	* hppa-hpux-tdep.c: Include "regset.h".
	(HPPA_HPUX_SS_WIDEREGS, HPPA_HPUX_SS_FLAGS_OFFSET)
	(HPPA_HPUX_SS_NARROW_OFFSET, HPPA_HPUX_SS_FPBLOCK_OFFSET)
	(HPPA_HPUX_SS_WIDE_OFFSET, HPPA_HPUX_SAVE_STATE_SIZE)
	(HPPA_HPUX_PA89_SAVE_STATE_SIZE): New defines.
	(hppa_hpux_supply_ss_narrow, hppa_hpux_supply_ss_fpblock)
	(hppa_hpux_supply_ss_wide, hppa_hpux_supply_save_state): New
	functions.
	(hppa_hpux_regset): New variable.
	(hppa_hpux_regset_from_core_section): New function.
	(hppa_hpux_init_abi): Set regset_from_core_section.
	(hppa_hpux_core_osabi_sniffer): New function.
	(_initialize_hppa_hpux_tdep): Register
	hppa_hpux_core_osabi_sniffer.
	* Makefile.in (hppa-hpux-tdep.o): Update dependencies.
	* config/pa/hppahpux.mt (TDEPFILES): Add corelow.o.

Index: hppa-hpux-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/hppa-hpux-tdep.c,v
retrieving revision 1.29
diff -u -p -r1.29 hppa-hpux-tdep.c
--- hppa-hpux-tdep.c 8 Dec 2004 01:48:01 -0000 1.29
+++ hppa-hpux-tdep.c 9 Dec 2004 22:27:48 -0000
@@ -23,7 +23,6 @@
 #include "arch-utils.h"
 #include "gdbcore.h"
 #include "osabi.h"
-#include "gdb_string.h"
 #include "frame.h"
 #include "frame-unwind.h"
 #include "trad-frame.h"
@@ -32,11 +31,15 @@
 #include "inferior.h"
 #include "infcall.h"
 #include "observer.h"
-#include "hppa-tdep.h"
+#include "regset.h"
+
+#include "gdb_string.h"
 
 #include <dl.h>
 #include <machine/save_state.h>
 
+#include "hppa-tdep.h"
+
 #ifndef offsetof
 #define offsetof(TYPE, MEMBER) ((unsigned long) &((TYPE *)0)->MEMBER)
 #endif
@@ -1418,6 +1421,148 @@ hppa_hpux_push_dummy_code (struct gdbarc
 \f
 
 /* Bit in the `ss_flag' member of `struct save_state' that indicates
+   that the 64-bit register values are live.  From
+   <machine/save_state.h>.  */
+#define HPPA_HPUX_SS_WIDEREGS		0x40
+
+/* Offsets of various parts of `struct save_state'.  From
+   <machine/save_state.h>.  */
+#define HPPA_HPUX_SS_FLAGS_OFFSET	0
+#define HPPA_HPUX_SS_NARROW_OFFSET	4
+#define HPPA_HPUX_SS_FPBLOCK_OFFSET 	256
+#define HPPA_HPUX_SS_WIDE_OFFSET        640
+
+/* The size of `struct save_state.  */
+#define HPPA_HPUX_SAVE_STATE_SIZE	1152
+
+/* The size of `struct pa89_save_state', which corresponds to PA-RISC
+   1.1, the lowest common denominator that we support.  */
+#define HPPA_HPUX_PA89_SAVE_STATE_SIZE	512
+
+static void
+hppa_hpux_supply_ss_narrow (struct regcache *regcache,
+			    int regnum, const char *save_state)
+{
+  const char *ss_narrow = save_state + HPPA_HPUX_SS_NARROW_OFFSET;
+  int i, offset = 0;
+
+  for (i = HPPA_R1_REGNUM; i < HPPA_FP0_REGNUM; i++)
+    {
+      if (regnum == i || regnum == -1)
+	regcache_raw_supply (regcache, i, ss_narrow + offset);
+
+      offset += 4;
+    }
+}
+
+static void
+hppa_hpux_supply_ss_fpblock (struct regcache *regcache,
+			     int regnum, const char *save_state)
+{
+  const char *ss_fpblock = save_state + HPPA_HPUX_SS_FPBLOCK_OFFSET;
+  int i, offset = 0;
+
+  /* FIXME: We view the floating-point state as 64 single-precision
+     registers for 32-bit code, and 32 double-precision register for
+     64-bit code.  This distinction is artificial and should be
+     eliminated.  If that ever happens, we should remove the if-clause
+     below.  */
+
+  if (register_size (get_regcache_arch (regcache), HPPA_FP0_REGNUM) == 4)
+    {
+      for (i = HPPA_FP0_REGNUM; i < HPPA_FP0_REGNUM + 64; i++)
+	{
+	  if (regnum == i || regnum == -1)
+	    regcache_raw_supply (regcache, i, ss_fpblock + offset);
+
+	  offset += 4;
+	}
+    }
+  else
+    {
+      for (i = HPPA_FP0_REGNUM; i < HPPA_FP0_REGNUM + 32; i++)
+	{
+	  if (regnum == i || regnum == -1)
+	    regcache_raw_supply (regcache, i, ss_fpblock + offset);
+
+	  offset += 8;
+	}
+    }
+}
+
+static void
+hppa_hpux_supply_ss_wide (struct regcache *regcache,
+			  int regnum, const char *save_state)
+{
+  const char *ss_wide = save_state + HPPA_HPUX_SS_WIDE_OFFSET;
+  int i, offset = 8;
+
+  if (register_size (get_regcache_arch (regcache), HPPA_R1_REGNUM) == 4)
+    offset += 4;
+
+  for (i = HPPA_R1_REGNUM; i < HPPA_FP0_REGNUM; i++)
+    {
+      if (regnum == i || regnum == -1)
+	regcache_raw_supply (regcache, i, ss_wide + offset);
+
+      offset += 8;
+    }
+}
+
+static void
+hppa_hpux_supply_save_state (const struct regset *regset,
+			     struct regcache *regcache,
+			     int regnum, const void *regs, size_t len)
+{
+  const char *proc_info = regs;
+  const char *save_state = proc_info + 8;
+  ULONGEST flags;
+
+  flags = extract_unsigned_integer (save_state + HPPA_HPUX_SS_FLAGS_OFFSET, 4);
+  if (regnum == -1 || regnum == HPPA_FLAGS_REGNUM)
+    {
+      struct gdbarch *arch = get_regcache_arch (regcache);
+      size_t size = register_size (arch, HPPA_FLAGS_REGNUM);
+      char buf[8];
+
+      store_unsigned_integer (buf, size, flags);
+      regcache_raw_supply (regcache, HPPA_FLAGS_REGNUM, buf);
+    }
+
+  /* If the SS_WIDEREGS flag is set, we really do need the full
+     `struct save_state'.  */
+  if (flags & HPPA_HPUX_SS_WIDEREGS && len < HPPA_HPUX_SAVE_STATE_SIZE)
+    error ("Register set contents too small");
+
+  if (flags & HPPA_HPUX_SS_WIDEREGS)
+    hppa_hpux_supply_ss_wide (regcache, regnum, save_state);
+  else
+    hppa_hpux_supply_ss_narrow (regcache, regnum, save_state);
+
+  hppa_hpux_supply_ss_fpblock (regcache, regnum, save_state);
+}
+
+/* HP-UX register set.  */
+
+static struct regset hppa_hpux_regset =
+{
+  NULL,
+  hppa_hpux_supply_save_state
+};
+
+static const struct regset *
+hppa_hpux_regset_from_core_section (struct gdbarch *gdbarch,
+				    const char *sect_name, size_t sect_size)
+{
+  if (strcmp (sect_name, ".reg") == 0
+      && sect_size >= HPPA_HPUX_PA89_SAVE_STATE_SIZE + 8)
+    return &hppa_hpux_regset;
+
+  return NULL;
+}
+\f
+
+/* Bit in the `ss_flag' member of `struct save_state' that indicates
    the state was saved from a system call.  From
    <machine/save_state.h>.  */
 #define HPPA_HPUX_SS_INSYSCALL	0x02
@@ -1532,6 +1677,9 @@ hppa_hpux_init_abi (struct gdbarch_info 
   set_gdbarch_write_pc (gdbarch, hppa_hpux_write_pc);
   set_gdbarch_unwind_pc (gdbarch, hppa_hpux_unwind_pc);
 
+  set_gdbarch_regset_from_core_section
+    (gdbarch, hppa_hpux_regset_from_core_section);
+
   frame_unwind_append_sniffer (gdbarch, hppa_hpux_sigtramp_unwind_sniffer);
 
   observer_attach_inferior_created (hppa_hpux_inferior_created);
@@ -1557,9 +1705,24 @@ hppa_hpux_elf_init_abi (struct gdbarch_i
   hppa_hpux_init_abi (info, gdbarch);
 }
 
+static enum gdb_osabi
+hppa_hpux_core_osabi_sniffer (bfd *abfd)
+{
+  if (strcmp (bfd_get_target (abfd), "hpux-core") == 0)
+    return GDB_OSABI_HPUX_SOM;
+
+  return GDB_OSABI_UNKNOWN;
+}
+
 void
 _initialize_hppa_hpux_tdep (void)
 {
+  /* BFD doesn't set a flavour for HP-UX style core files.  It doesn't
+     set the architecture either.  */
+  gdbarch_register_osabi_sniffer (bfd_arch_unknown,
+				  bfd_target_unknown_flavour,
+				  hppa_hpux_core_osabi_sniffer);
+
   gdbarch_register_osabi (bfd_arch_hppa, 0, GDB_OSABI_HPUX_SOM,
                           hppa_hpux_som_init_abi);
   gdbarch_register_osabi (bfd_arch_hppa, bfd_mach_hppa20w, GDB_OSABI_HPUX_ELF,
Index: Makefile.in
===================================================================
RCS file: /cvs/src/src/gdb/Makefile.in,v
retrieving revision 1.676
diff -u -p -r1.676 Makefile.in
--- Makefile.in 7 Dec 2004 22:17:59 -0000 1.676
+++ Makefile.in 9 Dec 2004 22:27:51 -0000
@@ -1975,9 +1975,9 @@ hppa-hpux-nat.o: hppa-hpux-nat.c $(defs_
 	$(target_h) $(gdb_assert_h) $(hppa_tdep_h) $(inf_ptrace_h) \
 	$(inf_ttrace_h)
 hppa-hpux-tdep.o: hppa-hpux-tdep.c $(defs_h) $(arch_utils_h) $(gdbcore_h) \
-	$(osabi_h) $(gdb_string_h) $(frame_h) $(frame_unwind_h) \
-	$(trad_frame_h) $(symtab_h) $(objfiles_h) $(inferior_h) $(infcall_h) \
-	$(observer_h) $(hppa_tdep_h)
+	$(osabi_h) $(frame_h) $(frame_unwind_h) $(trad_frame_h) $(symtab_h) \
+	$(objfiles_h) $(inferior_h) $(infcall_h) $(observer_h) $(regset_h) \
+	$(gdb_string_h) $(hppa_tdep_h)
 hppa-linux-nat.o: hppa-linux-nat.c $(defs_h) $(gdbcore_h) $(regcache_h) \
 	$(gdb_string_h) $(inferior_h) $(hppa_tdep_h) $(gregset_h)
 hppa-linux-tdep.o: hppa-linux-tdep.c $(defs_h) $(gdbcore_h) $(osabi_h) \
Index: config/pa/hppahpux.mt
===================================================================
RCS file: /cvs/src/src/gdb/config/pa/hppahpux.mt,v
retrieving revision 1.5
diff -u -p -r1.5 hppahpux.mt
--- config/pa/hppahpux.mt 5 Dec 2004 19:41:37 -0000 1.5
+++ config/pa/hppahpux.mt 9 Dec 2004 22:27:51 -0000
@@ -1,4 +1,4 @@
 # Target: HP PA-RISC running hpux
 MT_CFLAGS = -DPA_SOM_ONLY=1
-TDEPFILES= hppa-tdep.o hppa-hpux-tdep.o somread.o hpread.o somsolib.o
+TDEPFILES= hppa-tdep.o hppa-hpux-tdep.o corelow.o somread.o hpread.o somsolib.o
 DEPRECATED_TM_FILE= tm-hppah.h

Re: [RFC] Modernize HP-UX core file handling

[Randolph Chung]

Mark, I haven't had a chance to test your patch yet. I will do that
tomorrow. But in the recent past, core file handling was completely
broken on both hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11 (it always
segfaults when reading a core file for me), so i suspect whatever you
have will be better (at least a step in the right direction)

thanks for fixing this! it's very frustrating to have gdb coredump over
your core files....

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [RFC] Modernize HP-UX core file handling

[Mark Kettenis]

   Date: Thu, 9 Dec 2004 23:44:58 -0800
   From: Randolph Chung <randolph@tausq.org>

   Mark, I haven't had a chance to test your patch yet. I will do that
   tomorrow. But in the recent past, core file handling was completely
   broken on both hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11 (it always
   segfaults when reading a core file for me), so i suspect whatever you
   have will be better (at least a step in the right direction)

Ah, so there is no real point in waiting to check it in then; I can't
really break anything ;-).

   thanks for fixing this! it's very frustrating to have gdb coredump over
   your core files....

It's in now.  Test it whenever you feel like it.

Thanks,

Mark

Re: [RFC] Modernize HP-UX core file handling

[Joel Brobecker]

> Mark, I haven't had a chance to test your patch yet. I will do that
> tomorrow. But in the recent past, core file handling was completely
> broken on both hppa2.0w-hp-hpux11.11 and hppa64-hp-hpux11.11 (it always
> segfaults when reading a core file for me), so i suspect whatever you
> have will be better (at least a step in the right direction)

Hmmm, bizarre. I thought it was working fine for me (at least not
crashing), but I must have been using 6.3. With head, I got:

    This GDB was configured as "hppa2.0w-hp-hpux11.00"...
    (gdb) core core
    Core was generated by `crash'.
    Program terminated with signal 6, Aborted.
    Register flags not found in core file.

(but no crash, like you). I'm running on 11.00.

After Mark's changes, I get something much better:

    (gdb) bt
    #0  0xc01f5e38 in kill () from /usr/lib/libc.2
    #1  0x00002988 in cause_crash () from ./crash
    Cannot access memory at address 0xffffffed

I'll look at the unwinding failure when I have a moment.

Nice work, Mark!
-- 
Joel

Re: [RFC] Modernize HP-UX core file handling

[Joel Brobecker]

> After Mark's changes, I get something much better:
> 
>     (gdb) bt
>     #0  0xc01f5e38 in kill () from /usr/lib/libc.2
>     #1  0x00002988 in cause_crash () from ./crash
>     Cannot access memory at address 0xffffffed
> 
> I'll look at the unwinding failure when I have a moment.

Hmmm, I had a look at the problem above, and I'm a bit non-plussed...

First, the code:

        #include <sys/types.h>
        #include <signal.h>
        
        void
        cause_crash (void)
        {
          kill (getpid (), SIGABRT);
        }
        
        int
        main (void)
        {
          cause_crash ();
        
          return 0;
        }

Do the following (I used something close to GCC 3.4.3):

        % gcc -o crash crash.c
        % ulimit -c 100000
        % ./crash

This should produce a core file that GDB should be able to debug.
But the backtrace command fails:

        (gdb) core core
        (gdb) bt
        #0  0xc01f5e38 in kill () from /usr/lib/libc.2
        #1  0x00002988 in cause_crash ()
        warning: Cannot access memory at address 0xffffffed

Here is the assembly file for cause_crash():

        (gdb) disass
        Dump of assembler code for function cause_crash:
        0x00002958 <cause_crash+0>:     stw rp,-14(,sp)
        0x0000295c <cause_crash+4>:     copy r3,r1
        0x00002960 <cause_crash+8>:     copy sp,r3
        0x00002964 <cause_crash+12>:    stw,ma r1,40(,sp)
        0x00002968 <cause_crash+16>:    stw r3,-4(,sp)
        0x0000296c <cause_crash+20>:    b,l 0x2928 <getpid>,rp
        0x00002970 <cause_crash+24>:    nop
        0x00002974 <cause_crash+28>:    copy ret0,r19
        0x00002978 <cause_crash+32>:    copy r19,r26
        0x0000297c <cause_crash+36>:    ldi 6,r25
        0x00002980 <cause_crash+40>:    b,l 0x2940 <kill>,rp
        0x00002984 <cause_crash+44>:    nop
        0x00002988 <cause_crash+48>:    ldw -14(,r3),rp
        0x0000298c <cause_crash+52>:    ldo 40(r3),sp
        0x00002990 <cause_crash+56>:    ldw,mb -40(,sp),r3
        0x00002994 <cause_crash+60>:    bv,n r0(rp)
        End of assembler dump.

As you see, rp is saved at sp - 20 @+0 (all good), and then sp is
saved in r3 @+8 before sp is incremented by 64 bytes @+12. That's
where GDB says the function prologue ends.

However, the instruction right after that, at +16 saves r3 on the
stack at sp - 4. GDB didn't see that. So some logic in GDB that
says that if Save_SP is set in the function unwind record is set
and the FP register is non zero, then the FP register holds the
frame base:

     if (frame_pc_unwind (next_frame) >= prologue_end
         && u->Save_SP && fp != 0)

The problem is that somehow r3 got clobbered during the call to kill,
and no longer contains the frame base address (it contains 0x1). I am
a bit surprised by this, since r3 is supposed to be callee-save.  In any
case, GDB later fails when it uses that value as the base address where
to read the saved RP from.

The current code seems a bit more complicated than it needs to be,
at least to me. There is also a bit of duplication between the code that
analyzes the prologue, and the code that just skips it.  This mixture
between using part of the information from the unwind record, and
some other information derived from analyzing the prologue may
increase the complexity of the code. And also, the fact that the
HP native compiler and GCC do not use the same convention for the
frame (and the unwind record) makes it even more iffy. I am wondering
whether it might be possible to simplify all this by using the usual
approach relying mostly on prologue analysis and register tracking.

I'm just speaking aloud right now, sharing some general ideas, as fixing
the problem above within the current implementation does not seem easy
without resorting to a hack. And it almost feels that it would be a
hack on top on a pile of other hacks (no offense intended, it may be
my lack of knowledge of the pa/hpux architecture too). For instance,
if you look at the prologue skipping routine, you'll find that we
include all instructions at the begining of a function until we have
found where all registers are saved. We know before scanning the
instrunctions that the SP was saved, but we don't know that the register
containing the old SP has itself been saved on the stack. How to extend
the loop condition to include that possibility? The code computing
the frame cache also seems to be doing a lot of guessing... Perhaps
the same sort of cleanup as what we did with Andrew for mips would
be beneficial. It's something I'll keep on my long-term TODO list.

Anyway, just some thoughts.

-- 
Joel

Re: [RFC] Modernize HP-UX core file handling

[Randolph Chung]

> Do the following (I used something close to GCC 3.4.3):
> 
>         % gcc -o crash crash.c
>         % ulimit -c 100000
>         % ./crash
> 
> This should produce a core file that GDB should be able to debug.
> But the backtrace command fails:
> 
>         (gdb) core core
>         (gdb) bt
>         #0  0xc01f5e38 in kill () from /usr/lib/libc.2
>         #1  0x00002988 in cause_crash ()
>         warning: Cannot access memory at address 0xffffffed

i wonder why this is still not working for me:

tausq@hiauly3:~/src/build/gdb$ gcc -o crashme crashme.c
tausq@hiauly3:~/src/build/gdb$ ./crashme
ABORT instruction (core dumped)
tausq@hiauly3:~/src/build/gdb$ ./gdb ./crashme ./core
[...]
warning: The shared libraries were not privately mapped; setting a
breakpoint in a shared library will not work until you rerun the program.

Reading symbols from /home/tausq/src/build/gdb/crashme...Segmentation fault (core dumped)

:-(

> The problem is that somehow r3 got clobbered during the call to kill,
> and no longer contains the frame base address (it contains 0x1). I am
> a bit surprised by this, since r3 is supposed to be callee-save.  In any
> case, GDB later fails when it uses that value as the base address where
> to read the saved RP from.

it will be useful to get the unwind record and disassembly for <kill>. 

> The current code seems a bit more complicated than it needs to be,
> at least to me. There is also a bit of duplication between the code that
> analyzes the prologue, and the code that just skips it. 

yeah, they are a bit duplicative; i thought about unifying them, but
they are not quite exactly the same. worse yet, we need to support two
different kinds of "skipping prologues" (as discussed in the comments)
:(

> This mixture
> between using part of the information from the unwind record, and
> some other information derived from analyzing the prologue may
> increase the complexity of the code.

is there another way? the unwind record itself does not give enough
information to determine the location of register values for a frame; it
only tells you how many registers are saved, so we still need to do code
reading to find out where they are actually saved. for your example, i'm
curious to know what "kill" looks like. if you placed a breakpoint on
kill (not the stub, but the real kill) and do a backtrace on a running
process, does it work?

> And also, the fact that the
> HP native compiler and GCC do not use the same convention for the
> frame (and the unwind record) makes it even more iffy. I am wondering
> whether it might be possible to simplify all this by using the usual
> approach relying mostly on prologue analysis and register tracking.

well, without using the unwind information, how do you determine 
where the prologue ends? how do you determine if e.g. r3 is being used
as a "regular" register or a frame pointer?

> I'm just speaking aloud right now, sharing some general ideas, as fixing
> the problem above within the current implementation does not seem easy
> without resorting to a hack. And it almost feels that it would be a
> hack on top on a pile of other hacks (no offense intended, it may be
> my lack of knowledge of the pa/hpux architecture too). For instance,
> if you look at the prologue skipping routine, you'll find that we
> include all instructions at the begining of a function until we have
> found where all registers are saved. We know before scanning the
> instrunctions that the SP was saved, but we don't know that the register
> containing the old SP has itself been saved on the stack. How to extend
> the loop condition to include that possibility? The code computing
> the frame cache also seems to be doing a lot of guessing... Perhaps
> the same sort of cleanup as what we did with Andrew for mips would
> be beneficial. It's something I'll keep on my long-term TODO list.
> 
> Anyway, just some thoughts.

i'm all ears to how we can simplify the code; we can possibly clean that
up a bit. the current code is mostly the result of fixing errors found
by the testsuite on hppa-linux. now that we are starting to do more hpux
stuff we are discovering more corner cases :( as long as we don't
compromise the results on hppa-linux i'm open to suggestions on how to
clean this up.

as you observed, gcc doesn't quite generate the same frame code as HP
compilers. This is a known problem, but since GDB is mostly consistent
with GCC, it's one that hasn't received a lot of attention.  The code
also contains workarounds for bugs in HP compilers (i wonder how old
that bit of code is) which doesn't help to simplify the code.

randolph
-- 
Randolph Chung
Debian GNU/Linux Developer, hppa/ia64 ports
http://www.tausq.org/

Re: [RFC] Modernize HP-UX core file handling

[John David Anglin]

> found where all registers are saved. We know before scanning the
> instrunctions that the SP was saved, but we don't know that the register
> containing the old SP has itself been saved on the stack.

Huh?  GCC uses r3 as the frame pointer.  When a frame pointer is
needed, SAVE_SP is set.  When SAVE_SP is set, current GCC versions
save the old SP at SP-4.  The SP-4 is set in the prologue and whenever
a dynamic stack allocation is performed.  Unfortunately, old versions
of GCC don't correctly save the old SP at SP-4.  However, r3 always
contains the old SP when SAVE_SP is set.  HP compilers don't set
SAVE_SP.  The SP-4 support was added to GCC to fix a problem with
the HP-UX unwind library.

I'm not surprised that gdb didn't see the save at SP-4 as this is
a relatively new GCC feature under HP-UX (this isn't done under linux).
This was for better support of the frame marker.  Note the frame
marker moves in a dynamic stack allocation (i.e, the old SP is always
at SP-4).  Thus, if SAVE_SP is set and you see a save to SP-4 in
the prologue, the old SP can always be found at SP-4.

Since r3 is a callee-saves register, it has to be saved on the stack
when SAVE_SP is set in the unwind info.

Hope that helps.

Dave
-- 
J. David Anglin                                  dave.anglin@nrc-cnrc.gc.ca
National Research Council of Canada              (613) 990-0752 (FAX: 952-6602)