From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6660 invoked by alias); 7 May 2005 19:37:47 -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 6640 invoked from network); 7 May 2005 19:37:42 -0000 Received: from unknown (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org with SMTP; 7 May 2005 19:37:42 -0000 Received: from zaretski (IGLD-80-230-69-180.inter.net.il [80.230.69.180]) by romy.inter.net.il (MOS 3.5.6-GR) with ESMTP id BDX69485 (AUTH halo1); Sat, 7 May 2005 22:37:34 +0300 (IDT) Date: Sat, 07 May 2005 19:37:00 -0000 From: "Eli Zaretskii" To: gdb@sourceware.org Message-ID: <01c5533c$Blat.v2.4$0259a620@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 In-reply-to: <20050507161938.GA11730@nevyn.them.org> (message from Daniel Jacobowitz on Sat, 7 May 2005 12:19:39 -0400) Subject: Re: RFC: Available registers as a target property Reply-to: Eli Zaretskii References: <20050506162029.GA30792@nevyn.them.org> <01c552ee$Blat.v2.4$e21a5dc0@zahav.net.il> <20050507161938.GA11730@nevyn.them.org> X-SW-Source: 2005-05/txt/msg00095.txt.bz2 > Date: Sat, 7 May 2005 12:19:39 -0400 > From: Daniel Jacobowitz > > I do plan to write documentation to go along with these changes. Thanks! > For sim and native targets, there are other architecture hooks and > bits of global state in GDB that the target can read and write. I hope we could find a way to come up with a common infrastructure that would unify all these types of targets. > > Also, is it indeed a fact that information about registers is the only > > issue GDB has to deal with in such situations? Maybe we need to think > > about a more general mechanism, even if for now we only pass > > register-related information. > > Do you have any examples? No examples, it was just a general observation. As long as you say you keep this is mind, I'm happy. > 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.