From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4826 invoked by alias); 11 Aug 2010 20:23:18 -0000 Received: (qmail 4813 invoked by uid 22791); 11 Aug 2010 20:23:17 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,TW_XC,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 11 Aug 2010 20:23:12 +0000 Received: (qmail 4092 invoked from network); 11 Aug 2010 20:23:11 -0000 Received: from unknown (HELO caradoc.them.org) (dan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 11 Aug 2010 20:23:11 -0000 Date: Wed, 11 Aug 2010 20:23:00 -0000 From: Daniel Jacobowitz To: Philippe Waroquiers Cc: gdb@sourceware.org Subject: Re: gdbserver target description: info reg displays or not according to group presence ??? Message-ID: <20100811202307.GN6088@caradoc.them.org> References: <626075219D624850B89B9E0A39D09734@soleil> <20100802023939.GA25401@caradoc.them.org> <42CE44B333DB4F8DB17A98AF7734D41F@soleil> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <42CE44B333DB4F8DB17A98AF7734D41F@soleil> User-Agent: Mutt/1.5.20 (2009-06-14) 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/msg00066.txt.bz2 On Mon, Aug 02, 2010 at 08:07:52PM +0200, Philippe Waroquiers wrote: > So, it looks like the code currently already accepts arbitrary > register group but that the doc about GROUP does not mention this. IMO, the documentation is authoritative here; it's a specification for what a valid description looks like. On the other hand, the attached patch may not work unless you have some other named group... I'm not sure what to do. 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. > >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 ... Turns out there's a better fix too. Does this work? -- Daniel Jacobowitz CodeSourcery 2010-08-11 Daniel Jacobowitz * i386-tdep.c (i386_register_reggroup_p): Use tdesc_register_in_reggroup_p. Index: i386-tdep.c =================================================================== RCS file: /cvs/src/src/gdb/i386-tdep.c,v retrieving revision 1.316 diff -u -p -r1.316 i386-tdep.c --- i386-tdep.c 22 Jun 2010 02:15:45 -0000 1.316 +++ i386-tdep.c 11 Aug 2010 20:11:31 -0000 @@ -3106,6 +3106,7 @@ i386_register_reggroup_p (struct gdbarch const struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch); int fp_regnum_p, mmx_regnum_p, xmm_regnum_p, mxcsr_regnum_p, ymm_regnum_p, ymmh_regnum_p; + int ret; /* Don't include pseudo registers, except for MMX, in any register groups. */ @@ -3122,6 +3123,10 @@ i386_register_reggroup_p (struct gdbarch if (group == i386_mmx_reggroup) return mmx_regnum_p; + ret = tdesc_register_in_reggroup_p (gdbarch, regnum, group); + if (ret != -1) + return ret; + xmm_regnum_p = i386_xmm_regnum_p (gdbarch, regnum); mxcsr_regnum_p = i386_mxcsr_regnum_p (gdbarch, regnum); if (group == i386_sse_reggroup)