From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1053 invoked by alias); 9 May 2005 16:32:27 -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 921 invoked from network); 9 May 2005 16:32:20 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 9 May 2005 16:32:20 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50) id 1DVBB6-0005oG-EF; Mon, 09 May 2005 12:32:20 -0400 Date: Mon, 09 May 2005 16:32:00 -0000 From: Daniel Jacobowitz To: Paul Brook Cc: gdb@sourceware.org Subject: Re: RFC: Available registers as a target property Message-ID: <20050509163220.GC20242@nevyn.them.org> Mail-Followup-To: Paul Brook , gdb@sourceware.org References: <20050506162029.GA30792@nevyn.them.org> <200505091657.46412.paul@codesourcery.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200505091657.46412.paul@codesourcery.com> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00112.txt.bz2 On Mon, May 09, 2005 at 04:57:46PM +0100, Paul Brook wrote: > On Friday 06 May 2005 17:20, Daniel Jacobowitz wrote: > > set:: > >... > > reg:::::... > > Would it make sense to allow these two overlap? ie. if gdb can understand the > set it will use that and ignore the associated reg entries. If it doesn't > understand the set it will use the individual set entries. > > Assume I have an coprocessor not currently supported by gdb (Arm maverick for > the sake of argument), and a target that exposes maverick registers via reg:. > > At some time in the future gdb implements proper maverick support, and adds > set:maverick. Under your proposal I can't use my old gdb with my new target. > My new target doesn't generate reg: entries for maverick regs, and my old gdb > doesn't understand set:maverick. > > Obviously this is is purely a backwards compatibility QoI issue, and doesn't > matter if you expect everyone to use latest gdb. > > I'd suggest: > reg::::::... > > Where can be empty if the register doesn't belong to a known set. > In fact I guess including the set name in the reg: component makes the set: > component redundant. I've envisioned a different solution to this problem. The set information does not need to come from the target; GDB can recognize it via pattern information. "If we have eight registers named this of these types, and eight registers named that of those types, then that's this coprocessor". I do see that there's some fudge factor here because register names and types aren't a very good key. How about the tags field that I mentioned in my last mail to Mark, which is basically the same as set? If you report a set, you are relying upon GDB to recognize it or choose to ignore the associated registers. -- Daniel Jacobowitz CodeSourcery, LLC