From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6445 invoked by alias); 23 May 2002 20:57:59 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 6435 invoked from network); 23 May 2002 20:57:59 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 23 May 2002 20:57:59 -0000 Received: from redhat.com (reddwarf.sfbay.redhat.com [172.16.24.50]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id NAA02220; Thu, 23 May 2002 13:57:55 -0700 (PDT) Message-ID: <3CED547F.5411A523@redhat.com> Date: Thu, 23 May 2002 14:21:00 -0000 From: Michael Snyder Organization: Red Hat, Inc. X-Accept-Language: en MIME-Version: 1.0 To: Richard.Earnshaw@arm.com CC: Michael Snyder , gdb-patches@sources.redhat.com, rearnsha@arm.com Subject: Re: [RFA] Arm/Thumb tweak for generic_dummy_frames References: <200205220913.KAA18003@cam-mail2.cambridge.arm.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00881.txt.bz2 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 > > > * 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.