From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17933 invoked by alias); 17 Jan 2007 06:37:12 -0000 Received: (qmail 17920 invoked by uid 22791); 17 Jan 2007 06:37:12 -0000 X-Spam-Check-By: sourceware.org Received: from mtagate5.de.ibm.com (HELO mtagate5.de.ibm.com) (195.212.29.154) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 17 Jan 2007 06:37:06 +0000 Received: from d12nrmr1607.megacenter.de.ibm.com (d12nrmr1607.megacenter.de.ibm.com [9.149.167.49]) by mtagate5.de.ibm.com (8.13.8/8.13.8) with ESMTP id l0H6b3U1206112 for ; Wed, 17 Jan 2007 06:37:03 GMT Received: from d12av02.megacenter.de.ibm.com (d12av02.megacenter.de.ibm.com [9.149.165.228]) by d12nrmr1607.megacenter.de.ibm.com (8.13.8/8.13.8/NCO v8.2) with ESMTP id l0H6b2sb831742 for ; Wed, 17 Jan 2007 07:37:02 +0100 Received: from d12av02.megacenter.de.ibm.com (loopback [127.0.0.1]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l0H6b2aC016524 for ; Wed, 17 Jan 2007 07:37:02 +0100 Received: from [9.152.248.39] (dyn-9-152-248-39.boeblingen.de.ibm.com [9.152.248.39]) by d12av02.megacenter.de.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l0H6b2D8016519; Wed, 17 Jan 2007 07:37:02 +0100 Message-ID: <45ADC40B.6000500@de.ibm.com> Date: Wed, 17 Jan 2007 06:37:00 -0000 From: Markus Deuling User-Agent: Thunderbird 1.5.0.9 (X11/20070102) MIME-Version: 1.0 To: Mark Kettenis , gdb-patches@sourceware.org, drow@false.org Subject: Re: [RFA]: gdb/testsuite/gdb.arch/altivec-regs.exp Broken testcase References: <45AC7532.6010108@de.ibm.com> <200701162128.l0GLS1U4024821@brahms.sibelius.xs4all.nl> <20070117055939.GA19331@nevyn.them.org> In-Reply-To: <20070117055939.GA19331@nevyn.them.org> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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: 2007-01/txt/msg00382.txt.bz2 Hi, Daniel Jacobowitz schrieb: > Mark is right again. The fact that the testsuite isn't copying > should point us at the fact that the output changed, and we don't know > why. > > On Tue, Jan 16, 2007 at 10:28:01PM +0100, Mark Kettenis wrote: >> This worries me a bit. So in the past we were able to determine the >> endianness automagically, but now we don't? Do we understand why? >> Doesn't this mean that something is broken that worked before? > > More precisely: > >>> + -re "The target is assumed to be big endian.*" { >>> + pass "endianess" >>> + set endianness "big" >>> + } > > GDB has concluded from something (an earlier set command? one of my > gdbarch initialization changes?) that the user has specified the > endianness. > > Looking at it now, it looks to me like I've got a condition backwards > in show_endian. The != should actually be an ==. I can't test a patch > for that until I get home next week though. > Is that what you meant ? I changed if (target_byte_order_user != BFD_ENDIAN_UNKNOWN) to if (target_byte_order_user == BFD_ENDIAN_UNKNOWN) in show_endian(). x86: This GDB was configured as "i686-pc-linux-gnu". (gdb) show endian The target endianness is set automatically (currently little endian) So we wouldn't need the branch I inserted in altivec-regs.exp. But I think inserting +set endianness "" is a good idea. Then the testcase would have FAILed instead of abort with an error. Regards, Markus -- Markus Deuling GNU Toolchain for Linux on Cell BE deuling@de.ibm.com