From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3503 invoked by alias); 9 Apr 2002 06:43:11 -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 3324 invoked from network); 9 Apr 2002 06:43:10 -0000 Received: from unknown (HELO dberlin.org) (64.246.6.106) by sources.redhat.com with SMTP; 9 Apr 2002 06:43:10 -0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by dberlin.org (8.11.6/8.11.6) with ESMTP id g396h8m10720; Tue, 9 Apr 2002 02:43:08 -0400 Date: Mon, 08 Apr 2002 23:43:00 -0000 From: Daniel Berlin To: Andrew Cagney cc: gdb@sources.redhat.com Subject: Re: think-o: dwarf2 CFA != frame->frame (x86-64) In-Reply-To: <3CB27FF0.8050407@cygnus.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-04/txt/msg00116.txt.bz2 On Tue, 9 Apr 2002, Andrew Cagney wrote: > Hello, > > The x86-64 port, being the first to try to use dwarf2 cfa, is in the fun > position of having to figure out how to integrate some of this stuff > into gdb. Just noticed this one... > > x86-64 sets the function read_fp() to: > > set_gdbarch_read_fp (gdbarch, cfi_read_fp); > > And the corresponding code: > > /* Return the frame address. */ > CORE_ADDR > cfi_read_fp () > { > struct context *context; > struct frame_state *fs; > CORE_ADDR cfa; > > context = context_alloc (); > fs = frame_state_alloc (); > > context->ra = read_pc () + 1; > > frame_state_for (context, fs); > update_context (context, fs, 0); > > cfa = context->cfa; > unwind_tmp_obstack_free (); > return cfa; > } > > Going through the dwarf2++ spec, I've seen CFA (Call Frame Address) and > frame_base. While they might turn out to have the same value, they are, > I think, very different. > > The CFA is a CFI specific concept (all about how to unwind stack frames > and find register values) that, as far as I can tell, isn't intended for > ``public consumption''. It is used by the stack unwind code as a base > address for the frame being unwound. As far as > > Separate to this is the frame_base attribute of a function. My > interpretation of this attribute is that it defines the traditional > ``frame pointer''. > > I don't think x86-64-tdep.c should be using the CFA for frame->frame. > Instead it should be computing frame_base., > > I'll likely bug-report this. It might just be misnamed. I've converted rs6000 to use the dwarf2 cfa info (It's a little hairier, since on x86-64, you *always* have the info, it's part of the ABI), and it works just fine, even on optimized code. This is with the fallback to normal methods in case the info isn't in the executable, disabled, so i'd get errors if it wasn't using *only* the dwarf2 info. > > enjoy, > Andrew >