From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22794 invoked by alias); 9 May 2005 21:33:12 -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 22734 invoked from network); 9 May 2005 21:33:04 -0000 Received: from unknown (HELO mailapp.tensilica.com) (65.205.227.29) by sourceware.org with SMTP; 9 May 2005 21:33:04 -0000 Received: from localhost ([127.0.0.1] ident=amavis) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1DVFs8-0003aM-4k; Mon, 09 May 2005 14:33:04 -0700 Received: from mailapp.tensilica.com ([127.0.0.1]) by localhost (mailapp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 13349-05; Mon, 9 May 2005 14:33:04 -0700 (PDT) Received: from tux.hq.tensilica.com ([192.168.11.71]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1DVFs7-0003aD-QI; Mon, 09 May 2005 14:33:03 -0700 Message-ID: <427FD70E.2050608@tensilica.com> Date: Mon, 09 May 2005 21:33:00 -0000 From: Chris Zankel User-Agent: Mozilla Thunderbird 0.9 (X11/20041103) MIME-Version: 1.0 To: Daniel Jacobowitz CC: gdb@sources.redhat.com Subject: Re: RFC: Available registers as a target property References: <20050506162029.GA30792@nevyn.them.org> In-Reply-To: <20050506162029.GA30792@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-05/txt/msg00125.txt.bz2 Daniel Jacobowitz wrote: > Here's my current idea for an improved interface. Great! > 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. > 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? 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)? For example, in remote.c you could use something like this: for (regnum = 0; regnum < NUM_REGS + NUM_PSEUDO_REGS; regnum++) { struct packet_reg *r = &rs->regs[regnum]; if (gdbarch_pnum_to_regnum_p) r->pnum = gdbarch_pnum_to_regnum(regnum); else r->pnum = regnum; 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. > 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? ~Chris