From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 8983 invoked by alias); 17 Jan 2008 19:36:50 -0000 Received: (qmail 8970 invoked by uid 22791); 17 Jan 2008 19:36:49 -0000 X-Spam-Check-By: sourceware.org Received: from igw2.br.ibm.com (HELO igw2.br.ibm.com) (32.104.18.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 17 Jan 2008 19:36:24 +0000 Received: from mailhub3.br.ibm.com (mailhub3 [9.18.232.110]) by igw2.br.ibm.com (Postfix) with ESMTP id 40ADB17F585 for ; Thu, 17 Jan 2008 17:30:23 -0200 (BRDT) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v8.7) with ESMTP id m0HJaLm44247616 for ; Thu, 17 Jan 2008 17:36:21 -0200 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id m0HJaKtZ007037 for ; Thu, 17 Jan 2008 17:36:21 -0200 Received: from [9.18.238.41] (dyn531774.br.ibm.com [9.18.238.41] (may be forged)) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m0HJaKuk007007; Thu, 17 Jan 2008 17:36:20 -0200 Subject: Re: Printing decimal128 types out of registers From: Thiago Jung Bauermann To: luisgpm@linux.vnet.ibm.com Cc: gdb-patches@sourceware.org In-Reply-To: <1200596592.27321.20.camel@gargoyle> References: <1194460412.6686.34.camel@localhost> <1200596592.27321.20.camel@gargoyle> Content-Type: text/plain Date: Thu, 17 Jan 2008 19:36:00 -0000 Message-Id: <1200598580.32125.11.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.12.2 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-01/txt/msg00454.txt.bz2 On Thu, 2008-01-17 at 17:03 -0200, Luis Machado wrote: > Hi, > > The patch to handle DFP expressions had some overlapping with this > patch, and since this was a bit old already, follows a refreshed version > for HEAD. > > The patch remains essentially the same, with a few fixes. Running the > testsuite showed no regressions on 32-bit/64-bit ppc. > > Is this OK to go in? A few comments, mostly formatting: > + /* These are the e500 pseudo-registers. */ > + if (tdep->ppc_ev0_regnum >= 0 > + && regnum >= tdep->ppc_ev0_regnum > + && regnum < tdep->ppc_ev0_regnum + 32) > + return rs6000_builtin_type_vec64 (gdbarch); > + > + /* These are the ppc decimal128 pseudo-registers. */ > + if (tdep->ppc_dl0_regnum >= 0 > + && regnum >= tdep->ppc_dl0_regnum > + && regnum < tdep->ppc_dl0_regnum + 16) > + return builtin_type (current_gdbarch)->builtin_declong;; > > + /* These are the e500 pseudo-registers. */ > + if (tdep->ppc_ev0_regnum < 0 > + && regnum < tdep->ppc_ev0_regnum > + && regnum >= tdep->ppc_ev0_regnum + 32) > + return -1; > + > + /* These are the ppc decimal128 pseudo-registers. */ > + if (tdep->ppc_dl0_regnum < 0 > + && regnum < tdep->ppc_dl0_regnum > + && regnum >= tdep->ppc_dl0_regnum + 16) > + return -1; The return statements above are too indented. > - int have_fpu = 1, have_spe = 0, have_mq = 0, have_altivec = 0; > + int have_fpu = 1, have_spe = 0, have_mq = 0, have_altivec = 0, > + have_dfp128 = 0; have_dfp128 shouldn't be aligned with int. Not sure which column it should be though. > + else > + if (have_dfp128) > + { > + set_gdbarch_pseudo_register_read (gdbarch, ppc_pseudo_register_read); > + set_gdbarch_pseudo_register_write (gdbarch, ppc_pseudo_register_write); > + } > > + > + if (have_spe) > + set_gdbarch_num_pseudo_regs (gdbarch, 32); > + else > + if (have_dfp128) > + set_gdbarch_num_pseudo_regs (gdbarch, 16); IMHO, "else" should be immediately followed by if, not put in a separate line. > Index: gdb/features/rs6000/powerpc-64.c > [...] > Index: gdb/features/rs6000/powerpc-32.c These files are generated. You should edit the XML and regenerate. -- []'s Thiago Jung Bauermann Software Engineer IBM Linux Technology Center