From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sources.redhat.com
Subject: [RFA/alpha] Fetch register from the right frame
Date: Wed, 01 Dec 2004 02:42:00 -0000 [thread overview]
Message-ID: <20041201024220.GD1204@adacore.com> (raw)
[-- 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 = {
next reply other threads:[~2004-12-01 2:42 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-12-01 2:42 Joel Brobecker [this message]
2004-12-01 5:10 ` Daniel Jacobowitz
2004-12-01 17:08 ` Joel Brobecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20041201024220.GD1204@adacore.com \
--to=brobecker@adacore.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox