From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 787 invoked by alias); 9 May 2005 15:37:24 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 657 invoked from network); 9 May 2005 15:37:19 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 9 May 2005 15:37:19 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50) id 1DVAJq-0005Kk-VM; Mon, 09 May 2005 11:37:19 -0400 Date: Mon, 09 May 2005 15:37:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: gdb@sourceware.org Subject: Re: RFC: Available registers as a target property Message-ID: <20050509153718.GA20242@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , gdb@sourceware.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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c5533c$Blat.v2.4$0259a620@zahav.net.il> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00107.txt.bz2 On Sat, May 07, 2005 at 10:35:02PM +0300, Eli Zaretskii wrote: > > Thinking about it now, the parsing could be pushed down into the remote > > protocol implementation, and a C structure returned as a binary blob > > via target_read_partial. > > That's what I had in mind, sort of. > > > Do you think that would be a better interface to choose? > > I think so, but it's an idea based on general principles; I know much > less than you about the remote targets. So if you find that what I > suggested has any significant drawbacks, I won't insist. I've thought about this some more. I see one drawback, but it is definitely solvable. The data structure is not readily fixed-size. The target-specific data has no specified format, so it will be a binary (or probably ASCII) blob; the common format data will include character strings, e.g. the names of registers, which will have to be allocated somewhere. We don't want to leak them, so they need to have a defined lifetime. 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. -- Daniel Jacobowitz CodeSourcery, LLC