This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA] Arm/Thumb tweak for generic_dummy_frames
- From: Michael Snyder <msnyder at redhat dot com>
- To: Richard dot Earnshaw at arm dot com
- Cc: Michael Snyder <msnyder at cygnus dot com>, gdb-patches at sources dot redhat dot com, rearnsha at arm dot com
- Date: Thu, 23 May 2002 13:43:43 -0700
- Subject: Re: [RFA] Arm/Thumb tweak for generic_dummy_frames
- Organization: Red Hat, Inc.
- References: <200205220913.KAA18003@cam-mail2.cambridge.arm.com>
Richard Earnshaw wrote:
>
> msnyder@cygnus.com said:
> > This is a corner case that Andrew missed when he did the transition
> > to generic dummy frames.
>
> > 2002-05-21 Michael Snyder <msnyder@redhat.com>
>
> > * arm-tdep.c (arm_frame_chain): Recognize dummy-frame as a
> > special case that does not indicate a transition from arm
> > to thumb or vice versa.
>
> I can't (easily) work out from this what was wrong, and how you've fixed
> it. Could you provide some more detailed analysis?
Yeah, but not without drawing some pictures. ;-)
OK, here's the context. You're debugging in main, you put a breakpoint
at foo, and then you call foo, thusly:
(gdb) print foo()
(Let's say that main and foo are both thumb).
You hit the breakpoint, and now your runtime stack looks something like
this:
#0 foo
#1 dummy frame created by gdb
#2 main
At this point, GDB has already constructed a frame_info for foo,
doing all the prolog analysis and computing the saved registers.
So now you say "backtrace".
So gdb callse arm_frame_chain to find and start analyzing frame #1.
The first thing arm_frame_chain does is ask whether this frame
(frame #0) is a dummy frame. No, it's not, so we continue.
Then we compute the return address of frame #0, which for a
generic dummy frame is always the entry point address ("_start"
or crt0 or whatever).
Next, we compare the return address to the current frame's address,
to see whether we've made a transition between arm code and
thumb code. But this isn't a valid question if the caller_pc
is actually gdb's dummy frame, because the situation
(caller_pc == _start) is artificial. _start may be arm code,
and frame #0 may be thumb code, but we weren't actually called
from _start, so we don't want to act as if we were.
Now as to your second question --
> Why would a dummy frame never involve a transition between
> ARM and Thumb state?
Well, that's not what this change is actually about -- this change
is about thumb-calling-thumb (with a bogus "arm" dummy frame in
the middle). However, Andrew and I discussed what would happen
if you were in arm code and you tried to have GDB call a thumb
function (or vice versa), and decided that, well, we haven't
really handled that situation either before or after this change.
Someday we need to address it.
I guess I also should have mentioned that I ran testsuites
before and after. This change definitely fixes some failures,
and it doesn't introduce any new ones.