From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19557 invoked by alias); 12 Sep 2010 11:09:27 -0000 Received: (qmail 19546 invoked by uid 22791); 12 Sep 2010 11:09:26 -0000 X-SWARE-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_NONE,TW_CX,TW_DX,TW_EB X-Spam-Check-By: sourceware.org Received: from mailrelay012.isp.belgacom.be (HELO mailrelay012.isp.belgacom.be) (195.238.6.179) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 12 Sep 2010 11:09:20 +0000 X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAOZRjExtgFAz/2dsb2JhbACIc5hfcrtXDYUzBA Received: from 51.80-128-109.adsl-dyn.isp.belgacom.be (HELO soleil) ([109.128.80.51]) by relay.skynet.be with SMTP; 12 Sep 2010 13:09:17 +0200 Message-ID: From: "Philippe Waroquiers" To: "Philippe Waroquiers" , "Daniel Jacobowitz" Cc: References: <626075219D624850B89B9E0A39D09734@soleil> <20100802023939.GA25401@caradoc.them.org> <42CE44B333DB4F8DB17A98AF7734D41F@soleil> <20100811202307.GN6088@caradoc.them.org> <30E80C506E574886BE41DFFFD7E96F14@soleil> Subject: Re: gdbserver target description: info reg displays or not according to group presence ??? Date: Sun, 12 Sep 2010 11:09:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=response Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2010-09/txt/msg00075.txt.bz2 Can I give any additional info for the below ? Or help ? Thanks ----- Original Message ----- From: "Philippe Waroquiers" To: "Daniel Jacobowitz" Cc: Sent: Thursday, August 12, 2010 9:08 PM Subject: Re: gdbserver target description: info reg displays or not according to group presence ??? > Thanks for the reply/help. > >> The problem with letting people specify random strings as group is >> that GDB might grab those strings for a specific purpose in some >> future version. There's no registry or namespace. > Is this really a problem ? > From what I understand, a group is (only?) useful to (in the future) > allow to do 'info register ". > If there is really some behaviour linked with a register group, > then it is enough to specify something like: > "general", "all", "float", "vector", "save" and group names starting > with "g" are standard group names reserved for gdb usage. > >> Turns out there's a better fix too. Does this work? > It does not work according to the doc, but it provides > a consistent behaviour. The behaviour is: > if *no* group is given, then 'info reg' shows the registers. > > With the patch, the behaviour is: > * if no group is specified, then a register belongs to the general group. > * the general group is shown by 'info reg' > * other (gdb known) groups are shown by 'info reg ' > * info all-reg shows all registers > * and in the future, we could have > info reg shows the registers of this group. > > Here is some more detailed info about the behaviour with the patch: > > With the below (extract of) target description file: > ... > > > > > > > > > ... > > info register gives > ... > es 0x0 0 > fs 0x0 0 > gs 0x7b0000 8060928 > edxs1 0x0 0 > ebxs1 0x0 0 > esps1 0x0 0x0 > ... > > > So, specifying either a standard (float) or unknown (groupecxs1) > group makes these registers not shown. > But having no group at all (e.g. edxs1) still shows them. > > maint print register-groups gives: > ... > orig_eax 49 49 308 4 long save,restore,system > eaxs1 50 50 312 4 int32_t float,all,save,restore > ecxs1 51 51 316 4 int32_t all,save,restore > edxs1 52 52 320 4 int32_t general,all,save,restore > ... > > Philippe >