From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24610 invoked by alias); 2 Sep 2008 23:35:24 -0000 Received: (qmail 24601 invoked by uid 22791); 2 Sep 2008 23:35:24 -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; Tue, 02 Sep 2008 23:34:41 +0000 Received: from mailhub3.br.ibm.com (mailhub3 [9.18.232.110]) by igw2.br.ibm.com (Postfix) with ESMTP id 2375D17F5A0 for ; Tue, 2 Sep 2008 20:19:47 -0300 (BRT) 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 m82NVvo71655018 for ; Tue, 2 Sep 2008 20:32:02 -0300 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 m82NVopM001273 for ; Tue, 2 Sep 2008 20:31:50 -0300 Received: from [9.18.238.102] (dyn531835.br.ibm.com [9.18.238.102]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id m82NVoas001268; Tue, 2 Sep 2008 20:31:50 -0300 Subject: Re: [rfc] add ppc testcase to test fpscr From: Thiago Jung Bauermann To: Joel Brobecker Cc: gdb-patches ml In-Reply-To: <20080902213949.GH3774@adacore.com> References: <1219360611.8989.6.camel@localhost.localdomain> <20080821233115.GA1239@caradoc.them.org> <1219362081.29526.2.camel@localhost.localdomain> <20080822024659.GA12951@caradoc.them.org> <1219428669.8167.2.camel@localhost.localdomain> <20080902213949.GH3774@adacore.com> Content-Type: text/plain; charset=utf-8 Date: Tue, 02 Sep 2008 23:35:00 -0000 Message-Id: <1220398310.4204.22.camel@localhost.localdomain> Mime-Version: 1.0 X-Mailer: Evolution 2.22.3.1 Content-Transfer-Encoding: 8bit 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-09/txt/msg00036.txt.bz2 El mar, 02-09-2008 a las 23:39 +0200, Joel Brobecker escribió: > I didn't see anyone actually review the patch so I took a look. Thanks! > Looks OK to me, but I'm really wonderng why you added a '\r' at > the end of the expected output in our gdb_test calls. That was the closest I could think of to an EOL marker. Using '$' is not an option, I believe. > For instance: > > > +gdb_test "print \$fpscr" " = 0\r" "FPSCR is all zeroes" > > Usually, I just do: > > gdb_test "print \$fpscr" " = 0" "FPSCR is all zeroes" > > Is there something specific that you are trying to do with the '\r'? In the instance you show I agree it's not very useful, but here: > > +gdb_test "print/t \$fpscr" " = 10100000001000010001000000000000\r" "FPSCR for invalid operation" I want to be sure I am testing the lower 32-bits of the FPSCR. For the moment, this is meaningless since the FPSCR is assumed to always be 32 bits wide in GDB (also, the " = " in the beginning of the pattern doesn't help). But the FPSCR is actually 64 bits wide starting with Power ISA 2.05 (only Power6 at the moment). That's what I'm playing with which prompted me to write this testcase, actually. > > +#include > > Is the use of stdio necessary in this case. If you can do without, > then this would allow us to run this testcase in the bareboard case > (powerpc-elf). Not strictly necessary, but nice to have... I added the printf calls just to make sure GCC doesn't make the 'result' variable vanish. Maybe that's not necessary, since the asm blocks mention result as an output variable? Or maybe GCC would also nuke the asm blocks instead, seeing that they serve no useful purpose if 'result' is also not used? I don't know. -- []'s Thiago Jung Bauermann IBM Linux Technology Center