From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11956 invoked by alias); 20 Sep 2002 07:24:59 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 11830 invoked from network); 20 Sep 2002 07:24:58 -0000 Received: from unknown (HELO mx1.redhat.com) (66.187.233.31) by sources.redhat.com with SMTP; 20 Sep 2002 07:24:58 -0000 Received: from int-mx2.corp.redhat.com (nat-pool-rdu-dmz.redhat.com [172.16.52.200]) by mx1.redhat.com (8.11.6/8.11.6) with ESMTP id g8K77ai26162 for ; Fri, 20 Sep 2002 03:07:36 -0400 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx2.corp.redhat.com (8.11.6/8.11.6) with ESMTP id g8K7Otx27154; Fri, 20 Sep 2002 03:24:55 -0400 Received: from romulus.sfbay.redhat.com (IDENT:ebOKi75wsXffoyGe+4pAokVHPm8R5Xna@romulus.sfbay.redhat.com [172.16.27.251]) by potter.sfbay.redhat.com (8.11.6/8.11.6) with ESMTP id g8K7OsC01477; Fri, 20 Sep 2002 00:24:54 -0700 Received: (from kev@localhost) by romulus.sfbay.redhat.com (8.11.6/8.11.6) id g8K7Oq424100; Fri, 20 Sep 2002 00:24:52 -0700 Date: Fri, 20 Sep 2002 00:24:00 -0000 From: Kevin Buettner Message-Id: <1020920072452.ZM24099@localhost.localdomain> In-Reply-To: Andrew Cagney "[rfc] Add per frame frame_saved_pc()" (Sep 19, 11:30pm) References: <3D8A9662.1080902@ges.redhat.com> To: Andrew Cagney , gdb@sources.redhat.com Subject: Re: [rfc] Add per frame frame_saved_pc() MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-09/txt/msg00303.txt.bz2 On Sep 19, 11:30pm, Andrew Cagney wrote: > Back to (trumpet noises) CFI and more fall-out from the MIPS and generic > dummy frames. > > - The CFI doco describes a ``return_address_register'' which ``[...] > might not correspond to a machine register''. This means a CFI specific > frame saved PC method. I'm not certain that this should (necessarily) drive our decisions. > - Given a generic dummy frame, it knows exactly where the callers frame > PC is. No need to ask the target code. > > With this in mind, I'd like to propose making frame_saved_pc() a > per-frame method. I'd be willing to look at a patch. In particular, what I'm curious about it to see the places where the frame_saved_pc field is initialized in the frame. I can picture how the generic dummy frame code would look, but what I'm less clear about is what it'd look like for normal frames. It seems to me that you have two choices, 1) have a generic method which falls back on the current machinery, or 2) have architecture specific methods. I'm more interested in how (2) will be accomplished. Kevin