From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24001 invoked by alias); 23 Apr 2008 12:54:34 -0000 Received: (qmail 23941 invoked by uid 22791); 23 Apr 2008 12:54:33 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 23 Apr 2008 12:54:14 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 0F99A983DB for ; Wed, 23 Apr 2008 12:54:12 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id ED151980F7 for ; Wed, 23 Apr 2008 12:54:11 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1JoeUF-0005B4-69 for gdb-patches@sourceware.org; Wed, 23 Apr 2008 08:54:11 -0400 Date: Wed, 23 Apr 2008 13:44:00 -0000 From: Daniel Jacobowitz To: gdb-patches@sourceware.org Subject: Re: [PATCH] -stack-info-frame/-stack-list-frames Message-ID: <20080423125410.GA19773@caradoc.them.org> Mail-Followup-To: gdb-patches@sourceware.org References: <18446.45778.889114.789630@kahikatea.snap.net.nz> <200804230933.04964.vladimir@codesourcery.com> <18446.63716.779534.2827@kahikatea.snap.net.nz> <200804231349.35190.vladimir@codesourcery.com> <18447.12269.389044.431822@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <18447.12269.389044.431822@kahikatea.snap.net.nz> User-Agent: Mutt/1.5.17 (2007-12-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-04/txt/msg00518.txt.bz2 On Thu, Apr 24, 2008 at 12:47:41AM +1200, Nick Roberts wrote: > > My biggest worry about this is that we'll be providing some information > > which is highly compiler dependent and which we cannot document in any way > > other that "it is hex number". I don't think a random frontend author knows > > what DWARF CFI is :-) > > If it was just a hex number, the concept of frame address presumably wouldn't > exist. To me, it refers to the start of the frame and if a variable has an > address below that value, it belongs to that frame or a higher one. Maybe on > some architectures, the stack grows in the other direction, and maybe there are > other anomalies, but a user could understand this and interpret such numbers. My concern about this has been, and still is, that front ends will assign more meaning to it than it really has. This is one of the trickiest parts of GDB. We already use frame addresses (specifically $fp) to create varobjs in non-current frames; this is basically the only thing the entire complicated frame_base machinery is used for when not using stabs and it really should go away. How about we call it the stack address of the frame instead of the frame address? Then it can come from the unwound $sp, which will be at the other end of the frame and is better defined. -- Daniel Jacobowitz CodeSourcery