From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24219 invoked by alias); 9 Apr 2002 05:45:24 -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 24119 invoked from network); 9 Apr 2002 05:45:22 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 9 Apr 2002 05:45:22 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 6A1F63EF8 for ; Tue, 9 Apr 2002 01:45:20 -0400 (EDT) Message-ID: <3CB27FF0.8050407@cygnus.com> Date: Mon, 08 Apr 2002 22:45: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: gdb@sources.redhat.com Subject: think-o: dwarf2 CFA != frame->frame (x86-64) Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00115.txt.bz2 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. enjoy, Andrew