From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12350 invoked by alias); 9 May 2005 23:07:51 -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 12321 invoked from network); 9 May 2005 23:07:46 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 9 May 2005 23:07:46 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50) id 1DVHLm-0005HN-Cz; Mon, 09 May 2005 19:07:46 -0400 Date: Mon, 09 May 2005 23:07:00 -0000 From: Daniel Jacobowitz To: Chris Zankel Cc: gdb@sources.redhat.com Subject: Re: RFC: Available registers as a target property Message-ID: <20050509230746.GA20085@nevyn.them.org> Mail-Followup-To: Chris Zankel , gdb@sources.redhat.com References: <20050506162029.GA30792@nevyn.them.org> <427FD70E.2050608@tensilica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427FD70E.2050608@tensilica.com> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00127.txt.bz2 On Mon, May 09, 2005 at 02:33:02PM -0700, Chris Zankel wrote: > >GDB then reads the TARGET_OBJECT_AVAILABLE_REGISTERS object from the > >target, > >parses it, and hands it to the gdbarch for final processing. This means > >that the object must have a target-independent format, although it will > >have target-dependent content also. > > I am wondering if it would also make sense to support the other way > around and let GDB tell the target about the processor/register > configuration. A scenario for this would be where GDB talks to an OCD > daemon (=target) that controls the processor via JTAG. The daemon > wouldn't need to know everything about the processor configuration. The daemon would already have to be updated to understand any new protocol extensions, so we're talking about modifying that agent in any case. Given that, can you explain what advantage we would gain by having GDB pass configuration information to the daemon, instead of having the daemon parse some text file at startup and then communicate the configuration information to GDB? I don't want to support both directions just for kicks, but there may be value here that I haven't thought of yet. That's why I asked Tensilica for feedback. I expect that support for feeding GDB from information provided by a remote stub is actually orthogonal to telling a remote stub about our configuration. > >First of all, the target object. It can describe either individual > >registers or register sets known to the target (for brevity). Each > >component is an ASCII string. Colon is used as a field delimiter and > >semicolon as a component delimiter. A register set would look like: > > > > set:: > > Sorry, but what do you mean by 'protocol number'? Is that 'pnum' in > remote.c? A number specific to whatever protocol is being used. For the remote protocol that's the index into the g/G packet and the index used with p/P packets. So, yes. > The reason why I ask this is because although the current remote.c file > supports pnums, they are currently mapped 1:1 to regnum. It would be > great if you could allow a gdbarch to modify the that mapping. > > I guess this is what you mean by the following: > > > The architecture would have to register the remote protocol <-> gdb > > regcache number mapping. > > Do you intend to introduce a gdbarch function (for example, > gdbarch_pnum_to_regnum_p) and use it to define the pnum value in > remote.c (and other files)? Yes, this is already implemented on the branch I referenced in my original mail. It was fairly straightforward. I'm not sure how exhaustive it was, since I didn't try renumbering any of the g-packet registers, but in principle that's no harder. > In our case (Tensilica-Xtensa), we have a non-sequential register > encoding and use the pnum <-> regnum mapping. For example, all address > registers might have a pnum 0x10XX, special register 0x11XX, etc. That would work fine as long as you mapped them to sequential register numbers internal to GDB. > >For instance, if MIPS used this feature to expect 32-bit > >vs 64-bit GPRs, it would be desirable to continue using a g/G packet for > >those. > > I think that would be a nice feature. However, it probably requires > quite a few changes to the register cache, does it not? Not at all. The g packet is just the first however-many hard registers in the remote protocol numbering (those numbers may need to be sequential; not sure offhand). -- Daniel Jacobowitz CodeSourcery, LLC