From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-patches-return-14022-listarch-gdb-patches=sourceware.cygnus.com@sources.redhat.com>
Received: (qmail 29557 invoked by alias); 7 Apr 2002 02:08:25 -0000
Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-patches-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb-patches/>
List-Post: <mailto:gdb-patches@sources.redhat.com>
List-Help: <mailto:gdb-patches-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-patches-owner@sources.redhat.com
Received: (qmail 29445 invoked from network); 7 Apr 2002 02:08:22 -0000
Received: from unknown (HELO dberlin.org) (64.246.6.106)
  by sources.redhat.com with SMTP; 7 Apr 2002 02:08:22 -0000
Received: from localhost (localhost.localdomain [127.0.0.1])
	by dberlin.org (8.11.6/8.11.6) with ESMTP id g37281m28206;
	Sat, 6 Apr 2002 21:08:01 -0500
Date: Sat, 06 Apr 2002 18:08:00 -0000
From: Daniel Berlin <dan@dberlin.org>
To: Andrew Cagney <ac131313@cygnus.com>
cc: gdb-patches@sources.redhat.com
Subject: Re: [WIP]: LOC_COMPUTED and LOC_COMPUTED_ARG
In-Reply-To: <3CAF9F8E.6030607@cygnus.com>
Message-ID: <Pine.LNX.4.44.0204062103440.28166-100000@dberlin.org>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
X-SW-Source: 2002-04/txt/msg00243.txt.bz2

On Sat, 6 Apr 2002, Andrew Cagney wrote:

> > 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?
> > 
> > 
> > Theoretically you could, but it's sort of pointless.
> > You still end up doing the same lookup.
> > It also hides the code, since the code to create frames is nowhere 
> > near the dwarf2 reader.
> 
> I'm still missing something.  If dwarf2 info isn't used to compute 
> frame->base (and frame->prev->pc) where are the values comming from?

I'm confused now.
I grepped for frame->base, and find no occurrences of it.

Anyway, DW_OP_fbreg has a special meaning.
It specifically means "Use the value you get from evaluating the 
DW_AT_frame_base attribute of the current function".  So that's what we do.  
Even more specifically, "The DW_OP_fbreg operation provides a signed 
LEB128 offset from the address specified by the location description in 
the DW_AT_frame_base attribute of the current function."

I'm just doing what the spec says, nothing more, nothing less.
:)


> > Andrew
>