From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28007 invoked by alias); 1 Aug 2012 19:41:06 -0000 Received: (qmail 27999 invoked by uid 22791); 1 Aug 2012 19:41:05 -0000 X-SWARE-Spam-Status: No, hits=-4.1 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,MSGID_FROM_MTA_HEADER,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,TW_XF,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from e06smtp17.uk.ibm.com (HELO e06smtp17.uk.ibm.com) (195.75.94.113) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 01 Aug 2012 19:40:52 +0000 Received: from /spool/local by e06smtp17.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Wed, 1 Aug 2012 20:40:50 +0100 Received: from d06nrmr1407.portsmouth.uk.ibm.com (9.149.38.185) by e06smtp17.uk.ibm.com (192.168.101.147) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Wed, 1 Aug 2012 20:40:49 +0100 Received: from d06av02.portsmouth.uk.ibm.com (d06av02.portsmouth.uk.ibm.com [9.149.37.228]) by d06nrmr1407.portsmouth.uk.ibm.com (8.13.8/8.13.8/NCO v10.0) with ESMTP id q71Jemij1388714 for ; Wed, 1 Aug 2012 20:40:48 +0100 Received: from d06av02.portsmouth.uk.ibm.com (loopback [127.0.0.1]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVout) with ESMTP id q71Jemta002426 for ; Wed, 1 Aug 2012 13:40:48 -0600 Received: from tuxmaker.boeblingen.de.ibm.com (tuxmaker.boeblingen.de.ibm.com [9.152.85.9]) by d06av02.portsmouth.uk.ibm.com (8.14.4/8.13.1/NCO v10.0 AVin) with SMTP id q71Jeksr002407; Wed, 1 Aug 2012 13:40:46 -0600 Message-Id: <201208011940.q71Jeksr002407@d06av02.portsmouth.uk.ibm.com> Received: by tuxmaker.boeblingen.de.ibm.com (sSMTP sendmail emulation); Wed, 01 Aug 2012 21:40:46 +0200 Subject: Re: [PATCH] Adjust `pc-fp.exp' for ppc64/s390x (PR 12659) To: palves@redhat.com (Pedro Alves) Date: Wed, 01 Aug 2012 19:41:00 -0000 From: "Ulrich Weigand" Cc: sergiodj@redhat.com (Sergio Durigan Junior), gdb-patches@sourceware.org (GDB Patches), tromey@redhat.com (Tom Tromey), jan.kratochvil@redhat.com (Jan Kratochvil) In-Reply-To: <5018ECBE.4020007@redhat.com> from "Pedro Alves" at Aug 01, 2012 09:45:50 AM MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit x-cbid: 12080119-0542-0000-0000-000002A07741 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: 2012-08/txt/msg00034.txt.bz2 Pedro Alves wrote: > On 07/31/2012 10:25 PM, Sergio Durigan Junior wrote: > > While regtesting 7.4 against 7.5 branch on ppc64/s390x RHEL 6.3, I > > noticed this failure. The patch which introduced this failure was > > committed because of: > > > > http://sourceware.org/bugzilla/show_bug.cgi?id=12659 > > > > On x86*, the output of `info register pc fp' is: > > > > info register pc fp > > pc: 0x400520 > > fp: 0x7fffffffc490 > > (gdb) PASS: gdb.base/pc-fp.exp: info register pc fp > > > > On ppc64/s390x, it is: > > > > info register pc fp > > pc 0x10000658 0x10000658 > > fp: 0xfffffffd120 > > (gdb) FAIL: gdb.base/pc-fp.exp: info register pc fp > > > > Since this difference in the output does not seem to be an error itself, > > the patch below just adjusts the testcase to match this kind of output > > as well. It does not fail on x86*. > > Why is the output format different? It looks like consistency here would be good. The problem is that "pc", "fp", etc can refer to different things under the covers: either a register defined by the target code, or else a "user register" defined by GDB common code. On many targets (but not Intel), "pc" is the name of a register defined by the target. In this case, registers_info uses the standard gdbarch_print_registers_info routine to output its content; this gives a larger space between register name and value, and outputs the contents both in hex and in the register's default type, usually a function pointer type. On targets where "pc" is *not* the name of a register defined by the target, registers_info still recognizes the name as "user register", and uses a separate code path to print its value. This results in a different (shorter) output ... Bye, Ulrich -- Dr. Ulrich Weigand GNU Toolchain for Linux on System z and Cell BE Ulrich.Weigand@de.ibm.com