This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] Tru64 stack unwinding fix
- From: Andrew Cagney <ac131313 at cygnus dot com>
- To: Joel Brobecker <brobecker at gnat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Tue, 18 Jun 2002 19:52:00 -0400
- Subject: Re: [RFA] Tru64 stack unwinding fix
- References: <20020614120726.G17001@gnat.com>
I'm sorry the test case involves Ada, but that is the only way
I found to reproduce it at the time when I looked at this problem.
I suspect a non-ada aware GDB and a breakpoint on
*__hstTransferRegistersPC would do the trick :-)
Here is the ChangeLog:
2002-06-14 Joel Brobecker <brobecker@gnat.com>
* alpha-tdep.c (heuristic_proc_desc): Compute the size of the
current frame using only the first stack size adjustment. All
subsequent size adjustments are not considered to be part of
the "static" part of the current frame.
Compute the address of the saved registers relative to the
Frame Pointer ($fp) instead of the Stack Pointer if $fp is
in use in this frame.
Ok to commit?
Yes (you're in a better position then most to test it). The change to
handle FP and alloca() is very important and something often missed.
> + /* At this point, we know which of the Stack Pointer of the Frame
Pointer
.. or the ..
enjoy,
Andrew
PS: Some things unrelated to your patch I noticed:
! vfp = read_next_frame_reg (next_frame, ALPHA_GCC_FP_REGNUM);
I think someone should re-implement read_next_frame_reg() using:
/* Unwind the stack frame so that the value of REGNUM, in the previous
frame is returned. If VALUEP is NULL, don't fetch/compute the
value. Instead just return the location of the value. */
extern void frame_register_unwind (struct frame_info *frame, int regnum,
int *optimizedp, enum lval_type *lvalp,
CORE_ADDR *addrp, int *realnump,
void *valuep);
as this will work with CFI and generic dummy frames.