From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7625 invoked by alias); 10 May 2005 00:23:48 -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 7589 invoked from network); 10 May 2005 00:23:40 -0000 Received: from unknown (HELO mailapp.tensilica.com) (65.205.227.29) by sourceware.org with SMTP; 10 May 2005 00:23:40 -0000 Received: from localhost ([127.0.0.1] ident=amavis) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1DVIXE-0001N4-4V; Mon, 09 May 2005 17:23:40 -0700 Received: from mailapp.tensilica.com ([127.0.0.1]) by localhost (mailapp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 05027-02; Mon, 9 May 2005 17:23:40 -0700 (PDT) Received: from tux.hq.tensilica.com ([192.168.11.71]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1DVIXD-0001Mz-RU; Mon, 09 May 2005 17:23:39 -0700 Message-ID: <427FFF0A.8010800@tensilica.com> Date: Tue, 10 May 2005 00:23: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> <427FD70E.2050608@tensilica.com> <20050509230746.GA20085@nevyn.them.org> In-Reply-To: <20050509230746.GA20085@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-05/txt/msg00129.txt.bz2 Daniel Jacobowitz wrote: >>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. > 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 was thinking about an architecture with multiple configurations (registers), such as Arc, Tensilica, ARM coprocessors (?), etc. Having a single daemon supporting these multiple (arbitrary) configurations would probably be easier for JTAG probe vendors. Since GDB certainly needs to know about the particular configuration, the daemon wouldn't need to be modified for each configuration. > 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 understand. I was just wondering if this would be useful and actully agree that your proposal makes much more sense and that the target should know about the configuration. In our case, the daemon currently doesn't know about a particular configuration, and GDB only queries for registers the processor (better) has. For example, to read 'special register' , OCD simply issues a rsr a2, and doesn't know if this really exists. >>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. >>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. Note, however, that in our case, pnum is not the index into the g/G packet, and hopefully doesn't need to be? In cases where pnum is not sequential, you would also need a 'reverse' lookup function to get the register from pnum, something like this: static struct packet_reg * packet_reg_from_pnum (struct remote_state *rs, LONGEST pnum) { int i; for (i = 0; i < NUM_REGS + NUM_PSEUDO_REGS; i++) { struct packet_reg *r = &rs->regs[i]; if (r->pnum == pnum) return r; } return NULL; } Again, this function would only be called if gdbarch provided a pnum<->regnum mapping function. ~Chris