From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-21453-listarch-gdb=sources.redhat.com@sources.redhat.com>
Received: (qmail 18079 invoked by alias); 9 May 2005 15:57:54 -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 18000 invoked from network); 9 May 2005 15:57:49 -0000
Received: from unknown (HELO mail.codesourcery.com) (65.74.133.9)
  by sourceware.org with SMTP; 9 May 2005 15:57:49 -0000
Received: (qmail 2767 invoked from network); 9 May 2005 15:57:48 -0000
Received: from localhost (HELO 81-178-224-180.dsl.pipex.com) (paul@127.0.0.1)
  by mail.codesourcery.com with SMTP; 9 May 2005 15:57:48 -0000
From: Paul Brook <paul@codesourcery.com>
To: gdb@sourceware.org
Subject: Re: RFC: Available registers as a target property
Date: Mon, 09 May 2005 15:57:00 -0000
User-Agent: KMail/1.7.2
References: <20050506162029.GA30792@nevyn.them.org>
In-Reply-To: <20050506162029.GA30792@nevyn.them.org>
Cc: Daniel Jacobowitz <drow@false.org>
MIME-Version: 1.0
Content-Type: text/plain;
  charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
Message-Id: <200505091657.46412.paul@codesourcery.com>
X-SW-Source: 2005-05/txt/msg00108.txt.bz2

On Friday 06 May 2005 17:20, Daniel Jacobowitz wrote:
> 	set:<NAME>:<PROTOCOL NUMBER>
>...
> 	reg:<NAME>:<PROTOCOL NUMBER>:<BITSIZE>:<TYPE>:<TARGET DATA>...

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:<NAME>:<SET NAME>:<PROTOCOL NUMBER>:<BITSIZE>:<TYPE>:<TARGET DATA>...

Where <SET NAME> 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.

Paul