From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-21467-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 22912 invoked by alias); 9 May 2005 20:58:28 -0000
Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sources.redhat.com>
List-Archive: <http://sources.redhat.com/ml/gdb/>
List-Post: <mailto:gdb@sources.redhat.com>
List-Help: <mailto:gdb-help@sources.redhat.com>, <http://sources.redhat.com/ml/#faqs>
Sender: gdb-owner@sources.redhat.com
Received: (qmail 22843 invoked from network); 9 May 2005 20:58:21 -0000
Received: from unknown (HELO romy.inter.net.il) (192.114.186.66)
  by sourceware.org with SMTP; 9 May 2005 20:58:21 -0000
Received: from zaretski (IGLD-83-130-243-144.inter.net.il [83.130.243.144])
	by romy.inter.net.il (MOS 3.5.6-GR)
	with ESMTP id BEI43204 (AUTH halo1);
	Mon, 9 May 2005 23:58:10 +0300 (IDT)
Date: Mon, 09 May 2005 20:58:00 -0000
From: "Eli Zaretskii" <eliz@gnu.org>
To: gdb@sourceware.org
Message-ID: <01c554d9$Blat.v2.4$95050de0@zahav.net.il>
Content-Transfer-Encoding: 7BIT
Content-Type: text/plain; charset=ISO-8859-1
In-reply-to: <20050509153718.GA20242@nevyn.them.org> (message from Daniel
	Jacobowitz on Mon, 9 May 2005 11:37:18 -0400)
Subject: Re: RFC: Available registers as a target property
Reply-to: Eli Zaretskii <eliz@gnu.org>
References: <20050506162029.GA30792@nevyn.them.org> <01c552ee$Blat.v2.4$e21a5dc0@zahav.net.il> <20050507161938.GA11730@nevyn.them.org> <01c5533c$Blat.v2.4$0259a620@zahav.net.il> <20050509153718.GA20242@nevyn.them.org>
X-SW-Source: 2005-05/txt/msg00122.txt.bz2

> Date: Mon, 9 May 2005 11:37:18 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: gdb@sourceware.org
> 
> The target_read_partial interface is not well suited to that because
> the data may be transfered in multiple chunks; each time, we call down
> to the target.  The best thing I can think of would be to create the
> data structure once in the target, store it persistently, and then feed
> bits of that data structure back via to_xfer_partial.  This requires
> mutable data attached to the target object.  Nowadays we can use
> target_ops:to_data for this, so that should be OK.
> 
> This lets the target control the data lifetime.  Handy, since it allows
> for const structures for simulator targets, where we know the available
> features at compile time.
> 
> So that should work OK.

Sounds like a good plan.