From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-42976-listarch-gdb-patches=sources.redhat.com@sourceware.org>
Received: (qmail 18875 invoked by alias); 21 Feb 2006 22:59:13 -0000
Received: (qmail 18866 invoked by uid 22791); 21 Feb 2006 22:59:12 -0000
X-Spam-Check-By: sourceware.org
Received: from xproxy.gmail.com (HELO xproxy.gmail.com) (66.249.82.195)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 21 Feb 2006 22:59:11 +0000
Received: by xproxy.gmail.com with SMTP id s13so926031wxc         for <gdb-patches@sourceware.org>; Tue, 21 Feb 2006 14:59:09 -0800 (PST)
Received: by 10.70.61.11 with SMTP id j11mr5580213wxa;         Tue, 21 Feb 2006 14:59:09 -0800 (PST)
Received: by 10.70.125.17 with HTTP; Tue, 21 Feb 2006 14:59:08 -0800 (PST)
Message-ID: <8f2776cb0602211459u434690e7vc210196ad99a7b24@mail.gmail.com>
Date: Wed, 22 Feb 2006 04:28:00 -0000
From: "Jim Blandy" <jimb@red-bean.com>
To: "Mark Kettenis" <mark.kettenis@xs4all.nl>
Subject: Re: Fix a crash when stepping and unwinding fails
Cc: drow@false.org, sjackman@gmail.com, gdb-patches@sourceware.org
In-Reply-To: <200602212134.k1LLY3Sq028067@elgar.sibelius.xs4all.nl>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
Content-Disposition: inline
References: <20060220220331.GA29363@nevyn.them.org> 	 <200602212015.k1LKFGrj005090@elgar.sibelius.xs4all.nl> 	 <20060221202833.GA30161@nevyn.them.org> 	 <200602212050.k1LKowmP012208@elgar.sibelius.xs4all.nl> 	 <20060221205748.GA31483@nevyn.them.org> 	 <200602212134.k1LLY3Sq028067@elgar.sibelius.xs4all.nl>
X-IsSubscribed: yes
Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sourceware.org>
List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-patches-owner@sourceware.org
X-SW-Source: 2006-02/txt/msg00414.txt.bz2

On 2/21/06, Mark Kettenis <mark.kettenis@xs4all.nl> wrote:
> But get_current_frame() should be the innermost frame when we execute
> this code.  So the prologue analyzer can't be involved here.  However,
> yes, it seems that step_frame_idd can end up as null_frame_id, if
> get_current_frame() is also the outermost frame at the same time.

An alternative explanation to Daniel's: the base address in the ID of
frame #0 needs to be the base of the stack frame, so that it won't
change as the function executes and does whatever pushes and pops it
has in mind.  The only way to find the base of the stack frame is to
do prologue analysis or consult CFI.