From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12793 invoked by alias); 10 May 2005 21:08:06 -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 12541 invoked from network); 10 May 2005 21:08:01 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 10 May 2005 21:08:01 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50) id 1DVbxQ-0003E0-Ow; Tue, 10 May 2005 17:08:01 -0400 Date: Tue, 10 May 2005 21:08:00 -0000 From: Daniel Jacobowitz To: Chris Zankel Cc: gdb@sources.redhat.com Subject: Re: RFC: Available registers as a target property Message-ID: <20050510210800.GA12075@nevyn.them.org> Mail-Followup-To: Chris Zankel , gdb@sources.redhat.com References: <20050506162029.GA30792@nevyn.them.org> <427FD70E.2050608@tensilica.com> <20050509230746.GA20085@nevyn.them.org> <427FFF0A.8010800@tensilica.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <427FFF0A.8010800@tensilica.com> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00141.txt.bz2 On Mon, May 09, 2005 at 05:23:38PM -0700, Chris Zankel wrote: > 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'm afraid that doesn't answer my question :-) First of all, the daemon would not necessarily have to be modified for each configuration; it would need a different configuration file, which is not the same thing. Secondly, in this case, GDB _wouldn't_ need to know about the particular configuration. All the configuration information GDB needed, it could retrieve from the daemon. Sometimes, GDB needs configuration information and the target can supply it. Sometimes (apparently) the target needs information about its own configuration and GDB can supply it. I think we'll always be doing one or the other; one endpoint needs to have enough information for both rather than GDB needing to negotiate with the target. That suggests that the two configuration steps should be implemented independently. > >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. The options are to tell GDB about this directly, or to have the OCD tell GDB about the real properties of the target. I obviously prefer the latter when possible, because it allows GDB to gracefully handle binaries built for one configuration, and run on another configuration where they still work (but may be somehow affected by state they can not see). > >>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? Do you use a 'g' packet at all? Certainly you're free not to. If you do, then I'm not sure what it means with non-sequential pnums. > 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. You mean, like the function of that same name and implementation already in remote.c? Otherwise I'm not sure what you're talking about. -- Daniel Jacobowitz CodeSourcery, LLC