From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8431 invoked by alias); 12 Aug 2010 19:08:16 -0000 Received: (qmail 8421 invoked by uid 22791); 12 Aug 2010 19:08:15 -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 mailrelay005.isp.belgacom.be (HELO mailrelay005.isp.belgacom.be) (195.238.6.171) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 12 Aug 2010 19:08:06 +0000 X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAM/hY0xtgBl+/2dsb2JhbACIb5dGcr46DYUtBA Received: from 126.25-128-109.adsl-dyn.isp.belgacom.be (HELO soleil) ([109.128.25.126]) by relay.skynet.be with SMTP; 12 Aug 2010 21:08:03 +0200 Message-ID: <30E80C506E574886BE41DFFFD7E96F14@soleil> From: "Philippe Waroquiers" To: "Daniel Jacobowitz" Cc: References: <626075219D624850B89B9E0A39D09734@soleil> <20100802023939.GA25401@caradoc.them.org> <42CE44B333DB4F8DB17A98AF7734D41F@soleil> <20100811202307.GN6088@caradoc.them.org> Subject: Re: gdbserver target description: info reg displays or not according to group presence ??? Date: Thu, 12 Aug 2010 19:08:00 -0000 MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original 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-08/txt/msg00073.txt.bz2 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