Re: [patch/rfa/hppa] Use frame pointer for unwinding

Re: [patch/rfa/hppa] Use frame pointer for unwinding

[John David Anglin]

> ok. there is no gcc bug yet, but i will file one.

Bug?

> the fp != 0 is there probably because i don't understand correctly how
> the unwinder is working. if you have three frames:

> frame 3 - unwind from here
> frame 2 - doesn't save fp; fp should be constant in this function
> frame 1 - saves fp

Note that the the previous SP (frame pointer) is saved in the frame
marker of frame 1.  This value is accessible from frame 2 (i.e.,
effectively the frame pointer is always saved under hpux when Save_SP
is true -- it's just done by the caller).  However, I think gdb
should avoid using the saved SP value in the frame marker as not
all versions of GCC support this.  It's also not supported under
linux.

There are basically three situations generated by GCC:

1) The previous SP is saved at the start of the frame, the frame has
   a frame pointer (all alloca frames have a frame pointer) and Save_SP
   is set in the callinfo data.  Under hpux, the previous SP value
   is also saved at SP - 4 (8 on hppa64) in the frame marker.  This
   value is copied when a stack adjustment is done (i.e., the frame
   marker moves).

2) The frame uses register %r3 but doesn't have a frame pointer.  In
   this case, %r3 is saved along with the other general registers.

3) The frame does have a frame pointer or use %r3.  %r3 is not saved
   in the frame.

> frame 3 gets frame 2 as next_frame, will it be able to get the value of
> fp (from what is saved in frame 1)? it seems to work in my tests, but 
> i haven't yet figured out how it works in the code. if frame 2 doesn't
> save a register in its cache, is there some code that by default 
> propagates the values from the next frame?

If frame doesn't save %r3 either using method 1 or 2, then frame 2
leaves %r3 unchanged.

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

Re: [patch/rfa/hppa] Use frame pointer for unwinding

[Randolph Chung]

In reference to a message from John David Anglin, dated May 17:
> > ok. there is no gcc bug yet, but i will file one.
> 
> Bug?

ok, feature request? ;-) as noted below this is not really required for
gdb to work correctly; i'm just wondering if the same Save_SP scheme
works for both hp compiler and gcc. In some other email you had
indicated that the hp compiler doesn't set the Save_SP flag (or did 
i misunderstand you?)....

> Note that the the previous SP (frame pointer) is saved in the frame
> marker of frame 1.  This value is accessible from frame 2 (i.e.,
> effectively the frame pointer is always saved under hpux when Save_SP
> is true -- it's just done by the caller).  However, I think gdb
> should avoid using the saved SP value in the frame marker as not
> all versions of GCC support this.  It's also not supported under
> linux.

right now gdb uses the value of the frame pointer that is stored at the
start of the frame; that is, for "normal frames", it looks for a
specific code sequence:

stw,ma rN, xxx(sp)

in the code, and if it sees this, it notes that a frame pointer has 
been stored at offset 0 of the stack. During unwinding, it finds out 
if the current frame should have saved the fp (by looking at the Save_SP
flag) and if so it retrieves it from the stack.

> If frame doesn't save %r3 either using method 1 or 2, then frame 2
> leaves %r3 unchanged.

right; my question was more about how the value of the register gets
propagated in the gdb data structures. will look at the code some more.

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

Re: [patch/rfa/hppa] Use frame pointer for unwinding

[John David Anglin]

> ok, feature request? ;-) as noted below this is not really required for
> gdb to work correctly; i'm just wondering if the same Save_SP scheme
> works for both hp compiler and gcc. In some other email you had
> indicated that the hp compiler doesn't set the Save_SP flag (or did 
> i misunderstand you?)....

It's my understanding that none of the HP compilers set the Save_SP
flag.  This is why the flag was selected.  Originally, it indicated
that a frame pointer was needed for the frame.  Now, we also save
the entry value of SP in the current frame marker (current_SP - 4)
when a frame pointer is needed and TARGET_HPUX_UNWIND_LIBRARY is
true.

> > Note that the the previous SP (frame pointer) is saved in the frame
> > marker of frame 1.  This value is accessible from frame 2 (i.e.,
> > effectively the frame pointer is always saved under hpux when Save_SP
> > is true -- it's just done by the caller).  However, I think gdb
> > should avoid using the saved SP value in the frame marker as not
> > all versions of GCC support this.  It's also not supported under
> > linux.
> 
> right now gdb uses the value of the frame pointer that is stored at the
> start of the frame; that is, for "normal frames", it looks for a
> specific code sequence:
> 
> stw,ma rN, xxx(sp)
> 
> in the code, and if it sees this, it notes that a frame pointer has 
> been stored at offset 0 of the stack. During unwinding, it finds out 
> if the current frame should have saved the fp (by looking at the Save_SP
> flag) and if so it retrieves it from the stack.

A stw,ma r3, xxx(sp) instruction in the entry sequence is unique to
GCC (32-bit runtime).  If you find this, Save_SP should also be set
as it is part of the sequence to save %r3 and copy the stack pointer
to %r3 in a frame which needs a frame pointer..

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

Re: [patch/rfa/hppa] Use frame pointer for unwinding

[John David Anglin]

> > Anyway, I spoke with Dave Anglin (hppa gcc maintainer) about this. The
> > problem is that currently gcc/binutils does not correctly implement the
> > alloca_frame bit. The frame pointer is maintained in the case of a
> > variable-sized frame, but there is no flag set in the unwind record, and
> > the frame layout is slightly different compared to the HP compiler. It's
> > one of the things that should be fixed in gcc eventually. Also Dave has
> > observed that the Save_SP bit is set only for gcc; with the HP compiler
> > this is not set. Finally, with the HP compiler the frame pointer can be
> > maintained either in r3 or r4. It's not clear yet how this works. Some
> > more experimentation/disassembling HP code is required :-( I will add
> > some comments to the code about this situation. 
> 
> Is there a GCC bug report for this?

No.  GCC has always used a different frame layout than HP and set
Save_SP to indicate that the frame has a frame pointer.  Whether it
is a bug to not set the alloca_frame bit is an open question given
the different layout.

Ada uses the HP unwind library to a limited extent for backtraces.  I
believe that the frame marker support that GCC provides for the saved
SP value is sufficient for the library to unwind an alloca frame
without the alloca_frame bit being set.  We only do this under hpux
for compatibility with the HP library.

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

[patch/rfa/hppa] Use frame pointer for unwinding

[Randolph Chung]

One more patch --

Currently we don't use the frame pointer to unwind the stack, we rely
only on unwinding records. However, this doesn't work for functions that
call alloca() because the unwinding record does not account for the
variable-sized stack frame. In this case, the ABI requires that the
compiler always maintain a frame pointer.

Fixes these two FAILs from the testsuite, no new regressions.
+PASS: gdb.base/funcargs.exp: backtrace from call_after_alloca_subr
+PASS: gdb.base/selftest.exp: backtrace through signal handler

ok to apply?
randolph


2004-05-15  Randolph Chung  <tausq@debian.org>

	* hppa-tdep.c (hppa_frame_cache): If a frame pointer is available, use
	it for unwinding the stack.

Index: hppa-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/hppa-tdep.c,v
retrieving revision 1.156
diff -u -p -r1.156 hppa-tdep.c
--- hppa-tdep.c	8 May 2004 03:59:34 -0000	1.156
+++ hppa-tdep.c	16 May 2004 01:42:56 -0000
@@ -1761,15 +1798,26 @@ hppa_frame_cache (struct frame_info *nex
        the current function (and is thus equivalent to the "saved"
        stack pointer.  */
     CORE_ADDR this_sp = frame_unwind_register_unsigned (next_frame, HPPA_SP_REGNUM);
+    CORE_ADDR fp;
 
    if (hppa_debug)
       fprintf_unfiltered (gdb_stdlog, " (this_sp=0x%s, pc=0x%s, "
 		          "prologue_end=0x%s) ",
 		          paddr_nz (this_sp),
 			  paddr_nz (frame_pc_unwind (next_frame)),
 			  paddr_nz (prologue_end));
 
-    if (frame_pc_unwind (next_frame) >= prologue_end)
+    if (get_frame_type (next_frame) == NORMAL_FRAME
+        && u->Save_SP 
+	&& (fp = frame_unwind_register_unsigned (next_frame, HPPA_FP_REGNUM)))
+      {
+	cache->base = fp;
+
+	if (hppa_debug)
+	  fprintf_unfiltered (gdb_stdlog, " (base=0x%s) [frame pointer] }",
+			      paddr_nz (cache->base));
+      }
+    else if (frame_pc_unwind (next_frame) >= prologue_end)
       {
         if (u->Save_SP && trad_frame_addr_p (cache->saved_regs, HPPA_SP_REGNUM))
           {

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

Re: [patch/rfa/hppa] Use frame pointer for unwinding

[Mark Kettenis]

   Date: Sat, 15 May 2004 19:07:03 -0700
   From: Randolph Chung <randolph@tausq.org>


   -    if (frame_pc_unwind (next_frame) >= prologue_end)
   +    if (get_frame_type (next_frame) == NORMAL_FRAME
   +        && u->Save_SP 
   +	&& (fp = frame_unwind_register_unsigned (next_frame, HPPA_FP_REGNUM)))
   +      {
   +	cache->base = fp;

Randolph, this patch has a major style problem: assignments within an
if-statement are frowned upon.  Can you fix that?

Thanks,

Mark

Re: [patch/rfa/hppa] Use frame pointer for unwinding

[Randolph Chung]

> Randolph, this patch has a major style problem: assignments within an
> if-statement are frowned upon.  Can you fix that?

of course. is it ok otherwise?

randolph

2004-05-15  Randolph Chung  <tausq@debian.org>

	* hppa-tdep.c (hppa_frame_cache): If a frame pointer is available, use
	it for unwinding the stack.

Index: hppa-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/hppa-tdep.c,v
retrieving revision 1.156
diff -u -p -r1.156 hppa-tdep.c
--- hppa-tdep.c	8 May 2004 03:59:34 -0000	1.156
+++ hppa-tdep.c	16 May 2004 15:33:48 -0000
@@ -1761,15 +1798,28 @@ hppa_frame_cache (struct frame_info *nex
        the current function (and is thus equivalent to the "saved"
        stack pointer.  */
     CORE_ADDR this_sp = frame_unwind_register_unsigned (next_frame, HPPA_SP_REGNUM);
+    CORE_ADDR fp;
 
    if (hppa_debug)
       fprintf_unfiltered (gdb_stdlog, " (this_sp=0x%s, pc=0x%s, "
 		          "prologue_end=0x%s) ",
 		          paddr_nz (this_sp),
 			  paddr_nz (frame_pc_unwind (next_frame)),
 			  paddr_nz (prologue_end));
 
-    if (frame_pc_unwind (next_frame) >= prologue_end)
+    fp = frame_unwind_register_unsigned (next_frame, HPPA_FP_REGNUM);
+
+    if (get_frame_type (next_frame) == NORMAL_FRAME
+        && u->Save_SP 
+	&& fp != 0)
+      {
+	cache->base = fp;
+
+	if (hppa_debug)
+	  fprintf_unfiltered (gdb_stdlog, " (base=0x%s) [frame pointer] }",
+			      paddr_nz (cache->base));
+      }
+    else if (frame_pc_unwind (next_frame) >= prologue_end)
       {
         if (u->Save_SP && trad_frame_addr_p (cache->saved_regs, HPPA_SP_REGNUM))
           {

Re: [patch/rfa/hppa] Use frame pointer for unwinding

[Mark Kettenis]

   Date: Sun, 16 May 2004 08:36:38 -0700
   From: Randolph Chung <randolph@tausq.org>

   of course. is it ok otherwise?

What's the check for NORMAL_FRAME about?  Isn't hppa_frame_cache only
used for normal frames?  I'm not really familiar enough with HPPA to
judge whether this change is right.  All I can say is that this code
tends to have too much special cases, but that's not your fault...

Mark

Re: [patch/rfa/hppa] Use frame pointer for unwinding

[Randolph Chung]

> What's the check for NORMAL_FRAME about?  Isn't hppa_frame_cache only
> used for normal frames? 

hppa_frame_cache is only used when the current frame is a NORMAL_FRAME,
but the next frame can be anything.

> All I can say is that this code
> tends to have too much special cases, but that's not your fault...

yeah, it's really a bowl of spaghetti. I have some ideas about unifying
some of the code reading stuff and making it hopefully a bit cleaner.
got a few more bugs to fix first :)

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

Re: [patch/rfa/hppa] Use frame pointer for unwinding

[Andrew Cagney]

One more patch --

Currently we don't use the frame pointer to unwind the stack, we rely
only on unwinding records. However, this doesn't work for functions that
call alloca() because the unwinding record does not account for the
variable-sized stack frame. In this case, the ABI requires that the
compiler always maintain a frame pointer.
Fixes these two FAILs from the testsuite, no new regressions.
+PASS: gdb.base/funcargs.exp: backtrace from call_after_alloca_subr
+PASS: gdb.base/selftest.exp: backtrace through signal handler
ok to apply?
randolph
2004-05-15  Randolph Chung  <tausq@debian.org>

	* hppa-tdep.c (hppa_frame_cache): If a frame pointer is available, use
	it for unwinding the stack.


+    if (get_frame_type (next_frame) == NORMAL_FRAME
The unwinder shouldn't need to doing things conditional on the type of 
the next frame.  What does ``Variable_Frame'' mean?

Andrew.

Re: [patch/rfa/hppa] Use frame pointer for unwinding

[Randolph Chung]

> The unwinder shouldn't need to doing things conditional on the type of 
> the next frame.  

Let me see if i can rework this a bit. The problem is that when you
have:

signal frame
<signal trampoline>
normal frame
<dummy frame, code called from gdb>

the stack pointer in the dummy frame is wrong. the dummy frame uses the
sp returned by push_dummy_call () as the sp, but the unwinder follows
the frame pointer saved by the signal trampoline, and they don't match.

> What does ``Variable_Frame'' mean?

9. Variable_Frame (bit 17): Indicates that this region.s frame may be 
expanded during the region.s execution (using the Ada dynamic frame 
facility). Such frames require different unwinding techniques.

actually what you are probably interested in is this:

26. alloca_frame (bit 35): This bit is set if alloca() is used and has 
been inlined. This indicates gr3 or gr4 may contain the previous sp 
value.

For some reason this latter flag is named differently in the gdb sources
compared to what's in the documentation.

Anyway, I spoke with Dave Anglin (hppa gcc maintainer) about this. The
problem is that currently gcc/binutils does not correctly implement the
alloca_frame bit. The frame pointer is maintained in the case of a
variable-sized frame, but there is no flag set in the unwind record, and
the frame layout is slightly different compared to the HP compiler. It's
one of the things that should be fixed in gcc eventually. Also Dave has
observed that the Save_SP bit is set only for gcc; with the HP compiler
this is not set.  Finally, with the HP compiler the frame pointer can 
be maintained either in r3 or r4. It's not clear yet how this works. 
Some more experimentation/disassembling HP code is required :-( 
I will add some comments to the code about this situation.

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

Re: [patch/rfa/hppa] Use frame pointer for unwinding

[Randolph Chung]

> Let me see if i can rework this a bit. The problem is that when you
> have:
> 
> signal frame
> <signal trampoline>
> normal frame
> <dummy frame, code called from gdb>
> 
> the stack pointer in the dummy frame is wrong. the dummy frame uses the
> sp returned by push_dummy_call () as the sp, but the unwinder follows
> the frame pointer saved by the signal trampoline, and they don't match.

i think the problem is this -- i am looking at a failure in signals.exp.
there is a signal handler setup for SIGALARM. We "schedule" a signal to
be delivered via alarm(1), then do a "p func1()", and then a backtrace
from the signal handler:

Breakpoint 2, handler (sig=14)
    at ../../../gdb-work/gdb/testsuite/gdb.base/signals.c:22
22        signal (sig, handler);
The program being debugged stopped while in a function called from GDB.
When the function (func1) is done executing, GDB will silently
stop (instead of continuing to evaluate the expression containing
the function call).
(gdb) bt
#0  handler (sig=14) at ../../../gdb-work/gdb/testsuite/gdb.base/signals.c:22
#1  <signal handler called>
#2  func1 () at ../../../gdb-work/gdb/testsuite/gdb.base/signals.c:28
#3  <function called from gdb>
../../gdb-work/gdb/dummy-frame.c:300: internal-error: dummy_frame_prev_register: Assertion `dummy != NULL' failed.
A problem internal to GDB has been detected,
further debugging may prove unreliable.
Quit this debugging session? (y or n) n

What seems to be happening is that the signal handler is triggered
before the frame pointer is stored in func1:

(gdb) disassemble func1
Dump of assembler code for function func1:
0x000105f0 <func1+0>:   copy r3,r1
0x000105f4 <func1+4>:   copy sp,r3
0x000105f8 <func1+8>:   stw,ma r1,40(sr0,sp)  
[...]

the signal is triggered at 0x105f0, but the frame pointer is not saved
till 0x105f8. So, during unwinding, we notice that the signal frame has
the frame pointer stored, and use that to unwind the stack. Oops.

So, either:
- we don't allow the frame pointer to be used if the next frame is a
  SIGTRAMP_FRAME (similar to what i had before)
or:
- in the sigtramp unwinder, we don't restore the frame pointer

what is a better solution? or can anyone suggest a better alternative?

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

Re: [patch/rfa/hppa] Use frame pointer for unwinding

[Randolph Chung]

> What seems to be happening is that the signal handler is triggered
> before the frame pointer is stored in func1:

so, here's my 3rd try ;-)

2004-05-16  Randolph Chung  <tausq@debian.org>

	* hppa-tdep.c (hppa_frame_cache): If a frame pointer is available, use
	it for unwinding the stack.

Index: hppa-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/hppa-tdep.c,v
retrieving revision 1.156
diff -u -p -r1.156 hppa-tdep.c
--- hppa-tdep.c	8 May 2004 03:59:34 -0000	1.156
+++ hppa-tdep.c	17 May 2004 02:29:53 -0000
@@ -1761,15 +1798,42 @@ hppa_frame_cache (struct frame_info *nex
        the current function (and is thus equivalent to the "saved"
        stack pointer.  */
     CORE_ADDR this_sp = frame_unwind_register_unsigned (next_frame, HPPA_SP_REGNUM);
+    CORE_ADDR fp;
 
    if (hppa_debug)
       fprintf_unfiltered (gdb_stdlog, " (this_sp=0x%s, pc=0x%s, "
 		          "prologue_end=0x%s) ",
 		          paddr_nz (this_sp),
 			  paddr_nz (frame_pc_unwind (next_frame)),
 			  paddr_nz (prologue_end));
 
-    if (frame_pc_unwind (next_frame) >= prologue_end)
+    /* Check to see if a frame pointer is available, and use it for
+       frame unwinding if it is.
+
+       There are some situations where we need to rely on the frame
+       pointer to do stack unwinding.  For example, if a function calls
+       alloca (), the stack pointer can get adjusted inside the body of
+       the function.  In this case, the ABI requires that the compiler
+       maintain a frame pointer for the function.
+
+       The unwind record has a flag (alloca_frame) that indicates that
+       a function has a variable frame; unfortunately, gcc/binutils 
+       does not set this flag.  Instead, whenever a frame pointer is used
+       and saved on the stack, the Save_SP flag is set.  We use this to
+       decide whether to use the frame pointer for unwinding.  */
+
+    fp = frame_unwind_register_unsigned (next_frame, HPPA_FP_REGNUM);
+
+    if (frame_pc_unwind (next_frame) >= prologue_end
+        && u->Save_SP && fp != 0)
+      {
+	cache->base = fp;
+
+	if (hppa_debug)
+	  fprintf_unfiltered (gdb_stdlog, " (base=0x%s) [frame pointer] }",
+			      paddr_nz (cache->base));
+      }
+    else if (frame_pc_unwind (next_frame) >= prologue_end)
       {
         if (u->Save_SP && trad_frame_addr_p (cache->saved_regs, HPPA_SP_REGNUM))
           {

Re: [patch/rfa/hppa] Use frame pointer for unwinding

[Andrew Cagney]

+    /* Check to see if a frame pointer is available, and use it for
+       frame unwinding if it is.
+
+       There are some situations where we need to rely on the frame
+       pointer to do stack unwinding.  For example, if a function calls
+       alloca (), the stack pointer can get adjusted inside the body of
+       the function.  In this case, the ABI requires that the compiler
+       maintain a frame pointer for the function.
+
+       The unwind record has a flag (alloca_frame) that indicates that
+       a function has a variable frame; unfortunately, gcc/binutils 
+       does not set this flag.  Instead, whenever a frame pointer is used
+       and saved on the stack, the Save_SP flag is set.  We use this to
+       decide whether to use the frame pointer for unwinding.  */
+
+    fp = frame_unwind_register_unsigned (next_frame, HPPA_FP_REGNUM);
+
+    if (frame_pc_unwind (next_frame) >= prologue_end
+        && u->Save_SP && fp != 0)
fp will effectively always be non-zero here, so the ``fp != 0'' is a 
just-in-case?  Suggest adding that, and the GCC bug-number, as additions 
to the comments.

+      {
+	cache->base = fp;
+
+	if (hppa_debug)
+	  fprintf_unfiltered (gdb_stdlog, " (base=0x%s) [frame pointer] }",
+			      paddr_nz (cache->base));
+      }
+    else if (frame_pc_unwind (next_frame) >= prologue_end)
otherwize ok

Andrew

Re: [patch/rfa/hppa] Use frame pointer for unwinding

[Randolph Chung]

> >+    if (frame_pc_unwind (next_frame) >= prologue_end
> >+        && u->Save_SP && fp != 0)
> 
> fp will effectively always be non-zero here, so the ``fp != 0'' is a 
> just-in-case?  Suggest adding that, and the GCC bug-number, as additions 
> to the comments.

ok. there is no gcc bug yet, but i will file one.

the fp != 0 is there probably because i don't understand correctly how
the unwinder is working. if you have three frames:

frame 3 - unwind from here
frame 2 - doesn't save fp; fp should be constant in this function
frame 1 - saves fp

frame 3 gets frame 2 as next_frame, will it be able to get the value of
fp (from what is saved in frame 1)? it seems to work in my tests, but 
i haven't yet figured out how it works in the code. if frame 2 doesn't
save a register in its cache, is there some code that by default 
propagates the values from the next frame?

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

Re: [patch/rfa/hppa] Use frame pointer for unwinding

[Andrew Cagney]

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

fp will effectively always be non-zero here, so the ``fp != 0'' is a 
just-in-case?  Suggest adding that, and the GCC bug-number, as additions 
to the comments.


ok. there is no gcc bug yet, but i will file one.

the fp != 0 is there probably because i don't understand correctly how
the unwinder is working. if you have three frames:
frame 3 - unwind from here
frame 2 - doesn't save fp; fp should be constant in this function
frame 1 - saves fp
frame 3 gets frame 2 as next_frame, will it be able to get the value of
fp (from what is saved in frame 1)? it seems to work in my tests, but 
i haven't yet figured out how it works in the code. if frame 2 doesn't
(I'm assuming that the above stack backtrace is in reverse order to what 
GDB would display)

save a register in its cache, is there some code that by default 
propagates the values from the next frame?
yes, if frame-2 didn't save fp, then the trad-frame code will assume 
that frame-3's fp value is frame-2's fp value, and there for ask frame-1 
to unwind it (a recursive call).

Andrew

Re: [patch/rfa/hppa] Use frame pointer for unwinding

[Andrew Cagney]

26. alloca_frame (bit 35): This bit is set if alloca() is used and has 
been inlined. This indicates gr3 or gr4 may contain the previous sp 
value.

For some reason this latter flag is named differently in the gdb sources
compared to what's in the documentation.
(feel free to fix)

Anyway, I spoke with Dave Anglin (hppa gcc maintainer) about this. The
problem is that currently gcc/binutils does not correctly implement the
alloca_frame bit. The frame pointer is maintained in the case of a
variable-sized frame, but there is no flag set in the unwind record, and
the frame layout is slightly different compared to the HP compiler. It's
one of the things that should be fixed in gcc eventually. Also Dave has
observed that the Save_SP bit is set only for gcc; with the HP compiler
this is not set.  Finally, with the HP compiler the frame pointer can 
be maintained either in r3 or r4. It's not clear yet how this works. 
Some more experimentation/disassembling HP code is required :-( 
I will add some comments to the code about this situation.
Is there a GCC bug report for this?

(more followups to come)

Andrew