From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3078 invoked by alias); 7 Apr 2002 00:34:42 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 2879 invoked from network); 7 Apr 2002 00:34:41 -0000 Received: from unknown (HELO localhost.redhat.com) (24.112.240.27) by sources.redhat.com with SMTP; 7 Apr 2002 00:34:41 -0000 Received: from cygnus.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 588133CB7; Sat, 6 Apr 2002 19:34:32 -0500 (EST) Message-ID: <3CAF9418.2090607@cygnus.com> Date: Sat, 06 Apr 2002 16:34: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: Daniel Berlin Cc: gdb-patches@sources.redhat.com Subject: Re: [WIP]: LOC_COMPUTED and LOC_COMPUTED_ARG References: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg00239.txt.bz2 > + case DW_OP_fbreg: > + { > + struct symbol *framefunc; > + unsigned char *datastart; > + unsigned char *dataend; > + struct dwarf_block *theblock; > + struct locexpr_baton *baton; > + > + framefunc = get_frame_function (frame); > + op_ptr = read_sleb128 (op_ptr, &offset); > + baton = SYMBOL_LOCATION_BATON (framefunc); > + theblock = &baton->locexpr; > + datastart = theblock->data; > + dataend = theblock->data + theblock->size; > + result = execute_stack_op (var, datastart, dataend, frame, 0, NULL) + offset; > + } > + break; and > - the frame base address (for DW_OP_fbreg) > > > Not possible. > the frame base can be a location list. > That's why it pulls it out of the frame function on the fly. Something I've never understood. Shouldn't frame_base be stored in frame->base as part of the initial frame creation. Hence avoiding this recursion? Andrew