From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-23641-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 3067 invoked by alias); 7 Dec 2005 02:12:39 -0000
Received: (qmail 3059 invoked by uid 22791); 7 Dec 2005 02:12:37 -0000
X-Spam-Check-By: sourceware.org
Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 07 Dec 2005 02:12:35 +0000
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) 	by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id jB72CYOo023489 	for <gdb@sources.redhat.com>; Tue, 6 Dec 2005 21:12:34 -0500
Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156]) 	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id jB72CYV08715; 	Tue, 6 Dec 2005 21:12:34 -0500
Received: from [172.16.50.30] (vpn50-30.rdu.redhat.com [172.16.50.30]) 	by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id jB72CX6j030474; 	Tue, 6 Dec 2005 21:12:33 -0500
Message-ID: <43964434.1000103@redhat.com>
Date: Wed, 07 Dec 2005 02:12:00 -0000
From: Andrew Cagney <cagney@redhat.com>
User-Agent: Mozilla Thunderbird 1.0.7-1.1.fc4 (X11/20050929)
MIME-Version: 1.0
To: pgilliam@us.ibm.com
CC: Jim Blandy <jimb@redhat.com>, gdb@sources.redhat.com
Subject: Re: What should be used instead of deprecated_read_memory_nobpt()?
References: <200511291401.30945.pgilliam@us.ibm.com> <20051129221457.GB2238@nevyn.them.org> <8f2776cb0511291736t50824645pefa5c0db1edcbe49@mail.gmail.com> <200511301021.32626.pgilliam@us.ibm.com>
In-Reply-To: <200511301021.32626.pgilliam@us.ibm.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2005-12/txt/msg00069.txt.bz2

Jim here is obviously correct  <<there is always a frame>> was intended 
as mantra.  How would some choose to put it, a simplistic phrase to 
capture the imagination of the masses?

There are at least three parts to this:

-- the frame and a relationship to the thread, which in turn has an 
address space

-- as DanielJ points to it here:
/*NOTE: drow/2003-09-06: [...]
   They should be fixed as above, but meanwhile, we needed a solution for
   cases where functions are called with a NULL frame meaning either "the
   program is not running" or "use the selected frame".  Lazy building of
   deprecated_selected_frame confuses the situation, because now
   deprecated_selected_frame can be NULL even when the inferior is
   running. [...]
   ...
the need to also handle file-targets where the address space comes from 
a file

-- and finally the <<value <has-a> location>>, and that location could, 
in turn be a thread's memory, a frame's register, et.al.

It would be good to see these three aspects finally finally pulled 
together (works' a killer, sigh).

Andrew

PS: To clarify one thing, value persistance across resumptions of the 
inferior is implemented by fetching the value's contents, see 
record_latest_value:

  <<We don't want this value to have anything to do with the inferior
    anymore.  In particular, "set $1 = 50" should not affect the variable
    from which the value was taken, and fast watchpoints should be able
    to assume that a value on the value history never changes.>>

   if (value_lazy (val))
     value_fetch_lazy (val);