* [RFA/alpha] Fetch register from the right frame
@ 2004-12-01 2:42 Joel Brobecker
2004-12-01 5:10 ` Daniel Jacobowitz
0 siblings, 1 reply; 3+ messages in thread
From: Joel Brobecker @ 2004-12-01 2:42 UTC (permalink / raw)
To: gdb-patches
[-- Attachment #1: Type: text/plain, Size: 2332 bytes --]
Hello,
Trying to switch to gdb-6.3 on alpha-tru64, we noticed the following
problem:
(gdb) bt
#0 0x000003ff8057d43c in __hstTransferRegistersPC ()
from /usr/shlib/libpthread.so
#1 0x000003ff8056e8e4 in __osTransferContext ()
from /usr/shlib/libpthread.so
#2 0x000003ff80560c30 in __dspDispatch () from /usr/shlib/libpthread.so
#3 0x000003ff80560178 in __cvWaitPrim () from /usr/shlib/libpthread.so
#4 0x000003ff8055da9c in __pthread_cond_wait ()
from /usr/shlib/libpthread.so
#5 0x000000012002cf50 in system.tasking.rendezvous.wait_for_call ()
at s-tasren.adb:6
#6 0x00000001200296ec in system.tasking.rendezvous.accept_trivial ()
at s-tasren.adb:6
#7 0x000000012001e204 in task_switch.callee (<_task>=Cannot access memory at address 0x28
) at task_switch.adb:29
warning: Previous frame inner to this frame (corrupt stack?)
The two symptoms of the same problem are:
. "<_task>=Cannot access memory at address 0x28" at frame #7
. warning: Previous frame inner to this frame (corrupt stack?)
The callstack is missing the following two frames:
#8 0x0000000120027cfc in system.tasking.stages.task_wrapper ()
at s-tassta.adb:6
#9 0x000003ff8058a47c in __thdBase () from /usr/shlib/libpthread.so
I tracked the problem to alpha_heuristic_frame_prev_register():
Basically, after having verified that the register we'd like to fetch
has not been saved in by the next frame, we try to fetch the value
of the register inside the next frame. But instead, what we do, is
that we actually fetch the value of the register for the frame
*following* the next frame. Oups!
In our case above, instead of fetching the value of FP in
__pthread_cond_wait(), we end up fetching its value from __cvWaitPrim,
which contains the following instruction:
0x000003ff8055fc58 <__cvWaitPrim+72>: clr fp
So the value of FP becomes incorrect, and causes the backtrace
screwup later down the road when we try to read RA using an offset
from FP.
2004-11-30 Joel Brobecker <brobecker@gnat.com>
* alpha-tdep.c (alpha_heuristic_frame_prev_register): Fetch
the register value from the correct frame.
Tested on alpha-tru64 5.1, fixes the problem above, no regression
in the testsuite.
OK to apply?
Thanks,
--
Joel
[-- Attachment #2: reg.diff --]
[-- Type: text/plain, Size: 714 bytes --]
Index: alpha-tdep.c
===================================================================
RCS file: /nile.c/cvs/Dev/gdb/gdb-6.3/gdb/alpha-tdep.c,v
retrieving revision 1.1
diff -u -p -r1.1 alpha-tdep.c
--- alpha-tdep.c 20 Oct 2004 23:11:33 -0000 1.1
+++ alpha-tdep.c 30 Nov 2004 18:09:39 -0000
@@ -1190,8 +1190,8 @@ alpha_heuristic_frame_prev_register (str
}
/* Otherwise assume the next frame has the same register value. */
- frame_register (next_frame, regnum, optimizedp, lvalp, addrp,
- realnump, bufferp);
+ frame_register_unwind (next_frame, regnum, optimizedp, lvalp, addrp,
+ realnump, bufferp);
}
static const struct frame_unwind alpha_heuristic_frame_unwind = {
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFA/alpha] Fetch register from the right frame
2004-12-01 2:42 [RFA/alpha] Fetch register from the right frame Joel Brobecker
@ 2004-12-01 5:10 ` Daniel Jacobowitz
2004-12-01 17:08 ` Joel Brobecker
0 siblings, 1 reply; 3+ messages in thread
From: Daniel Jacobowitz @ 2004-12-01 5:10 UTC (permalink / raw)
To: Joel Brobecker; +Cc: gdb-patches
On Tue, Nov 30, 2004 at 06:42:20PM -0800, Joel Brobecker wrote:
> I tracked the problem to alpha_heuristic_frame_prev_register():
> Basically, after having verified that the register we'd like to fetch
> has not been saved in by the next frame, we try to fetch the value
> of the register inside the next frame. But instead, what we do, is
> that we actually fetch the value of the register for the frame
> *following* the next frame. Oups!
The patch seems OK to me. This is consistent with what other targets
do, also.
I have to stare at this a little bit each time... prev_register takes a
NEXT_FRAME argument. It is unwinding from THIS frame - which is not
one of its arguments - using THIS_CACHE. That's because a frame is
responsible for its own ID and the previous frame's registers. By the
time prev_register is called we have THIS frame available, but passing
it wouldn't do much good.
> 2004-11-30 Joel Brobecker <brobecker@gnat.com>
>
> * alpha-tdep.c (alpha_heuristic_frame_prev_register): Fetch
> the register value from the correct frame.
>
> Tested on alpha-tru64 5.1, fixes the problem above, no regression
> in the testsuite.
>
> OK to apply?
Yes.
--
Daniel Jacobowitz
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [RFA/alpha] Fetch register from the right frame
2004-12-01 5:10 ` Daniel Jacobowitz
@ 2004-12-01 17:08 ` Joel Brobecker
0 siblings, 0 replies; 3+ messages in thread
From: Joel Brobecker @ 2004-12-01 17:08 UTC (permalink / raw)
To: gdb-patches
> I have to stare at this a little bit each time...
Aaahhh, I feel better reading this :-).
> > 2004-11-30 Joel Brobecker <brobecker@gnat.com>
> >
> > * alpha-tdep.c (alpha_heuristic_frame_prev_register): Fetch
> > the register value from the correct frame.
> >
> > Tested on alpha-tru64 5.1, fixes the problem above, no regression
> > in the testsuite.
> >
> > OK to apply?
>
> Yes.
Thanks! Checked in.
--
Joel
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2004-12-01 17:08 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-12-01 2:42 [RFA/alpha] Fetch register from the right frame Joel Brobecker
2004-12-01 5:10 ` Daniel Jacobowitz
2004-12-01 17:08 ` Joel Brobecker
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox