From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26906 invoked by alias); 16 Apr 2002 15:02:04 -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 26838 invoked from network); 16 Apr 2002 15:01:53 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 16 Apr 2002 15:01:53 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 9AF053C71; Tue, 16 Apr 2002 11:01:55 -0400 (EDT) Message-ID: <3CBC3CE3.1020102@cygnus.com> Date: Tue, 16 Apr 2002 08:02:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:0.9.9) Gecko/20020328 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Jim Ingham Cc: gdb-patches@sources.redhat.com Subject: Re: infrun.c:restore_selected_frame??? References: <3CB35C2F.10003@cygnus.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00554.txt.bz2 I wrote: > Hmm, to more robustly identify a frame, should we save both the frame->frame and frame->pc (or containing function)? This is separate / independant - I've always wondered if frame->frame was sufficient. > > We do this in Project Builder, but there we do it because a GUI has to present the WHOLE stack frame every time you step, which is slow, so we optimize this by sending frame+pc duples to PB using a special purpose command that just gets these and doesn't reconstruct the whole stack. > > Don't know if you need this in gdb though. When did you think this might be a problem? Jim wrote: >> When did you think this might be a problem? I think I've I figured it out. To safely identify a frame, I think the ->addr/base and the ->func/pc are needed. The dwarf2cfi stuff drops the hint as to why. Consider a function that doesn't create a frame. A call through that function can result in two stack frames having the same ->frame value. They can only be differentiated by using the ->pc. I think, the correct way to identify a frame is to save: ->frame as before, a constant value that doesn't change through out the lifetime of the function ->func i.e. function_containing(->pc) (It turns out that, whenever a frame is created this is computed anyway!) I think ->func and not ->pc is needed so that it is possible to identify a frame at different points in its execution (eg stepping through the inner-most frame). -- dwarf2cfi doesn't allow for a (mutually) recursive frameless function (where both ->frame and ->func would be identical). enjoy, Andrew