From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9501 invoked by alias); 26 Mar 2003 21:51:23 -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 9494 invoked from network); 26 Mar 2003 21:51:23 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.105) by sources.redhat.com with SMTP; 26 Mar 2003 21:51:23 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 70EA02B23; Wed, 26 Mar 2003 16:51:13 -0500 (EST) Message-ID: <3E8220D1.90007@redhat.com> Date: Wed, 26 Mar 2003 21:51:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com Subject: Re: [patch rfc] Per-frame frame-base References: <3E820F82.6050803@redhat.com> <20030326210053.GA22425@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-03/txt/msg00526.txt.bz2 > On Wed, Mar 26, 2003 at 03:37:22PM -0500, Andrew Cagney wrote: > >> The implementation is very much modeled on the frame-unwind code. Debug >> readers are expected to register their own high level frame-base handler. > > > So what will the process for getting a dwarf2-debug-info frame > registered look like? The current interface is identical to frame-unwind. > How will we figure out that this function has > dwarf2 debug info? It's not trivial... we don't have that information > around any more on a per-PC basis. Ask the frame's function's symbol or block. > I'll have to think. > > >> +/* Assuming that a frame is `normal', return the address of the first >> + local variable, or 0 if the information isn't available. NOTE: >> + This address is really only meaningful to the frame's high-level >> + debug info. Typically, the argument and locals share a single >> + base-address. */ >> +extern CORE_ADDR get_frame_locals_address (struct frame_info *); >> + >> +/* Assuming that a frame is `normal', return the address of the first >> + parameter, or 0 if that information isn't available. NOTE: This >> + address is really only meaningful to the frame's high-level debug >> + info. Typically, the argument and locals share a single >> + base-address. */ >> +extern CORE_ADDR get_frame_args_address (struct frame_info *); >> + > > > Address of the first parameter / address of the first argument isn't > correct I think. It's the base address for parameters and the base > address from locals. They're likely to be the same but with different > offsets. You mean: ``Assuming that .., return the base address of the parameters'' Which may be different to the address of the first parameter since, even the first parameter's location may be specified as an offset from that base? Ok. Andrew