From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 333 invoked by alias); 2 Aug 2010 18:07:47 -0000 Received: (qmail 324 invoked by uid 22791); 2 Aug 2010 18:07:46 -0000 X-SWARE-Spam-Status: No, hits=1.1 required=5.0 tests=AWL,BAYES_50,RCVD_IN_DNSWL_NONE,TW_XC X-Spam-Check-By: sourceware.org Received: from mailrelay009.isp.belgacom.be (HELO mailrelay009.isp.belgacom.be) (195.238.6.176) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 02 Aug 2010 18:07:34 +0000 X-Belgacom-Dynamic: yes X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAG+lVkxtgIsY/2dsb2JhbACIbpcmcsQWDYUsBIQ9 Received: from 24.139-128-109.adsl-dyn.isp.belgacom.be (HELO soleil) ([109.128.139.24]) by relay.skynet.be with SMTP; 02 Aug 2010 20:07:31 +0200 Message-ID: <42CE44B333DB4F8DB17A98AF7734D41F@soleil> From: "Philippe Waroquiers" To: "Daniel Jacobowitz" Cc: References: <626075219D624850B89B9E0A39D09734@soleil> <20100802023939.GA25401@caradoc.them.org> Subject: Re: gdbserver target description: info reg displays or not according to group presence ??? Date: Mon, 02 Aug 2010 18:07: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/msg00015.txt.bz2 On Sun, 1 Aug 2010 22:39:47 -0400, Daniel Jacobowitz wrote: > Separately, note "must be". Don't use group="s1". Target-defined > register groups aren't supported. In target-description.c, I found the following comment: Arbitrary strings (other than "general", "float", and "vector") from the description are not used; they cause the register to be displayed in "info all-registers" but excluded from "info registers" et al. The names of containing features are also not used. This might be extended to display registers in some more useful groupings. I guess the idea is that one day, something like info registers a_target_defined_abitrary_group will show the registers of this group. So, it looks like the code currently already accepts arbitrary register group but that the doc about GROUP does not mention this. > Yes, it looks like a bug in i386_register_reggroup_p, in the last bit > (group == general_reggroup_p). One way to fix it would be to add a > range check (&& regnum < I386_NUM_GREGS). Not too sure of what I did but a small test seems ok with the below code: if (group == general_reggroup) return (!fp_regnum_p && !mmx_regnum_p && !mxcsr_regnum_p && !xmm_regnum_p && !ymm_regnum_p && !ymmh_regnum_p && regnum < I386_NUM_GREGS); Note that the tests above seems redundant: none of the registers below I386_NUM_GREGS are fp or mmx or ... Should I do a bug entry for this and also for clarifying the doc/comment ? The documentation of GROUP could probably be clarified and/or the comment in the code could be changed : * the code accepts any string as group name, doc does not mention this. * also the target xml files for i386 does not specify any group for e.g. eax, but eax is shown in info registers. I imagine we need an additional sentence such as "Pre-defined standard registers have an hard-coded set of groups. Use 'maint print register-groups' to look at these. The standard registers belonging to general group will be shown by 'info registers'." Philippe