From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14971 invoked by alias); 22 May 2002 21:28:19 -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 14945 invoked from network); 22 May 2002 21:28:18 -0000 Received: from unknown (HELO localhost.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 22 May 2002 21:28:18 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 27BF33D02; Wed, 22 May 2002 17:28:31 -0400 (EDT) Message-ID: <3CEC0D7E.1060906@cygnus.com> Date: Wed, 22 May 2002 22:01:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0rc2) Gecko/20020518 X-Accept-Language: en-us, 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; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-05/txt/msg00863.txt.bz2 > 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? Why would a dummy > frame never involve a transition between ARM and Thumb state? (I didn't really miss a corner case - the code was broken before/after the dummy frame conversion. The results for thumb are different to arm though). When you have an Arm v Thumb stack you see: Thumb-frame(Thumb FP) (callee) Arm-frame (Arm FP) (caller) The function frame_chain(Thumb-frame) needs to return the frame-pointer for the calling Arm-frame. To do this it first compares the caller and callee PC to check for a mode change. If one occure the callers prologue is examined to determine which register was used for the FP and hence, which register of the oposite mode needs to be unwound to obtain the frame chain. What it didn't handle was: Thumb-frame dummy-frame Arm-frame in fact, it was even messing up Thumb-frame dummy-frame Thumb-frame (and that is before my change :-) The problem being that the dummy-frame's PC is assumed to be Arm (based on symbol and address analysis). Michael's patch changes things to detect the presence of a dummy frame and then, for that case, assume the callee and caller are the same. It doesn't help thumb dummy arm though (but the old code didn't appear to handle that case either). enjoy, Andrew