From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8749 invoked by alias); 12 May 2005 23:35:13 -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 8720 invoked from network); 12 May 2005 23:35:07 -0000 Received: from unknown (HELO mailapp.tensilica.com) (65.205.227.29) by sourceware.org with SMTP; 12 May 2005 23:35:07 -0000 Received: from localhost ([127.0.0.1] ident=amavis) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1DWNCs-000384-BN; Thu, 12 May 2005 16:35:06 -0700 Received: from mailapp.tensilica.com ([127.0.0.1]) by localhost (mailapp [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 11760-07; Thu, 12 May 2005 16:35:06 -0700 (PDT) Received: from tux.hq.tensilica.com ([192.168.11.71]) by mailapp.tensilica.com with esmtp (Exim 4.34) id 1DWNCr-00037z-WB; Thu, 12 May 2005 16:35:06 -0700 Message-ID: <4283E829.1020008@tensilica.com> Date: Thu, 12 May 2005 23:35: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> <427FFF0A.8010800@tensilica.com> <20050510210800.GA12075@nevyn.them.org> In-Reply-To: <20050510210800.GA12075@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2005-05/txt/msg00146.txt.bz2 Daniel, (Sorry for the delay, but I had some mailer problems....) Daniel Jacobowitz wrote: > GDB _wouldn't_ need to > know about the particular configuration. All the configuration > information GDB needed, it could retrieve from the daemon. Hmmm... I have to think about it. It sounds like it could work. But that would be too easy, wouldn't it ;-) > 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. Agreed. > 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). This actually goes back to your comment above - I think. How do you tread 'pseudo' registers? Would it make sense to add 'flags' to the 'set' command? set::[:] >>>>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. > 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. At this point, we don't. However, with the changes you are planing to implement (thanks, btw.), we could probably use g/G again. >>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) > 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. Oops... I wasn't sure if I was looking at our code or the original GDB sources. It looks like GDB has support for non-sequential pnums, but doesn't allow to assign them from gdbarch. ~Chris