From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28073 invoked by alias); 12 Apr 2002 15:53:08 -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 28034 invoked from network); 12 Apr 2002 15:53:04 -0000 Received: from unknown (HELO cygnus.com) (205.180.83.203) by sources.redhat.com with SMTP; 12 Apr 2002 15:53:04 -0000 Received: from romulus.sfbay.redhat.com (romulus.sfbay.redhat.com [172.16.27.251]) by runyon.cygnus.com (8.8.7-cygnus/8.8.7) with ESMTP id IAA04211; Fri, 12 Apr 2002 08:53:00 -0700 (PDT) Received: (from kev@localhost) by romulus.sfbay.redhat.com (8.11.6/8.11.6) id g3CFqdT07139; Fri, 12 Apr 2002 08:52:39 -0700 Date: Fri, 12 Apr 2002 08:53:00 -0000 From: Kevin Buettner Message-Id: <1020412155238.ZM7138@localhost.localdomain> In-Reply-To: Andrew Cagney "Re: [rfc] frame->frame => frame->addr && frame->base()" (Apr 12, 9:38am) References: <200204121249.NAA02782@cam-mail2.cambridge.arm.com> <3CB6E371.6050801@cygnus.com> To: Andrew Cagney , Richard.Earnshaw@arm.com Subject: Re: [rfc] frame->frame => frame->addr && frame->base() Cc: gdb@sources.redhat.com MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-04/txt/msg00214.txt.bz2 On Apr 12, 9:38am, Andrew Cagney wrote: > >> // High level language concept of the base address of a frame. Often > >> refered to as ``frame_base'' or ``frame pointer''. This value should > >> only be computed on-demand. It is strongly recommended, though, that > >> implementations cache the computed value in the frame cache. The method > >> is initialized as part of the frame objects creation. The default > >> method returns frame->addr. (see dwarf2 DW_AT_frame_base) > >> > >> CORE_ADDR (*base) (struct frame_info *frame); > > > > What would this mean in the context of a function that doesn't use a frame > > pointer? What about a leaf function which doesn't store anything on the > > stack? I can't see how this can have any MI interpretation (other than > > the fact that all functions in a nested chain should have a different > > value). > > The value is debug-info dependant. See section 3.3.5 of the dwarf2 > spec. For some frames this value may not even be applicable - that is > ok because it isn't a requirement of a frame. If the value returned by frame->base() is debug-info dependent, then that would suggest that it could have different values for different types of debug info. That in turn suggests that you have to know what type of debug info you're dealing with at frame creation time so that frame->base can be initialized correctly. Of course, it could be done lazily. You could just initialize frame->base to lazy_base() (or whatever). lazy_base() would determine the function that's really required for that frame + debug info, reset the ->base field, and then invoke the function it's just calculated to obtain the desired value. Implementation details aside, this dependency causes me to wonder if it's really a good idea make this operation a member of the frame struct. Kevin