Message ID | m38tp8n5ol.fsf@oc1027705133.ibm.com |
---|---|
State | New, archived |
Headers |
Received: (qmail 93899 invoked by alias); 14 Feb 2017 15:38:53 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: <gdb-patches.sourceware.org> List-Unsubscribe: <mailto:gdb-patches-unsubscribe-##L=##H@sourceware.org> List-Subscribe: <mailto:gdb-patches-subscribe@sourceware.org> List-Archive: <http://sourceware.org/ml/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-help@sourceware.org>, <http://sourceware.org/ml/#faqs> Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 93804 invoked by uid 89); 14 Feb 2017 15:38:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.5 required=5.0 tests=AWL, BAYES_00, KAM_LAZY_DOMAIN_SECURITY, RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=$expect_out, expect_out, assemble, 1string X-HELO: mx0a-001b2d01.pphosted.com Received: from mx0a-001b2d01.pphosted.com (HELO mx0a-001b2d01.pphosted.com) (148.163.156.1) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 14 Feb 2017 15:38:46 +0000 Received: from pps.filterd (m0098399.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.20/8.16.0.20) with SMTP id v1EFciYd098610 for <gdb-patches@sourceware.org>; Tue, 14 Feb 2017 10:38:45 -0500 Received: from e06smtp12.uk.ibm.com (e06smtp12.uk.ibm.com [195.75.94.108]) by mx0a-001b2d01.pphosted.com with ESMTP id 28m2kge3cx-1 (version=TLSv1.2 cipher=AES256-SHA bits=256 verify=NOT) for <gdb-patches@sourceware.org>; Tue, 14 Feb 2017 10:38:44 -0500 Received: from localhost by e06smtp12.uk.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for <gdb-patches@sourceware.org> from <arnez@linux.vnet.ibm.com>; Tue, 14 Feb 2017 15:38:40 -0000 Received: from d06dlp03.portsmouth.uk.ibm.com (9.149.20.15) by e06smtp12.uk.ibm.com (192.168.101.142) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; Tue, 14 Feb 2017 15:38:37 -0000 Received: from b06cxnps4074.portsmouth.uk.ibm.com (d06relay11.portsmouth.uk.ibm.com [9.149.109.196]) by d06dlp03.portsmouth.uk.ibm.com (Postfix) with ESMTP id 214761B08070; Tue, 14 Feb 2017 15:41:33 +0000 (GMT) Received: from d06av26.portsmouth.uk.ibm.com (d06av26.portsmouth.uk.ibm.com [9.149.105.62]) by b06cxnps4074.portsmouth.uk.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id v1EFcbNW3539414; Tue, 14 Feb 2017 15:38:37 GMT Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id ED181AE058; Tue, 14 Feb 2017 14:36:28 +0000 (GMT) Received: from d06av26.portsmouth.uk.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id CDD97AE045; Tue, 14 Feb 2017 14:36:28 +0000 (GMT) Received: from oc1027705133.ibm.com (unknown [9.152.212.222]) by d06av26.portsmouth.uk.ibm.com (Postfix) with ESMTPS; Tue, 14 Feb 2017 14:36:28 +0000 (GMT) From: Andreas Arnez <arnez@linux.vnet.ibm.com> To: Yao Qi <qiyaoltc@gmail.com> Cc: "gdb-patches\@sourceware.org" <gdb-patches@sourceware.org> Subject: Re: [PATCH] Big-endian targets: Fix implptrpiece.exp References: <m3wpdrus83.fsf@oc1027705133.ibm.com> <CAH=s-PON2KZnCBgC6XeuJxegqsdbLs8b=CeCbdmPzvO=kbs-0w@mail.gmail.com> Date: Tue, 14 Feb 2017 16:38:34 +0100 In-Reply-To: <CAH=s-PON2KZnCBgC6XeuJxegqsdbLs8b=CeCbdmPzvO=kbs-0w@mail.gmail.com> (Yao Qi's message of "Tue, 14 Feb 2017 12:59:13 +0000") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/25.1 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-TM-AS-GCONF: 00 X-Content-Scanned: Fidelis XPS MAILER x-cbid: 17021415-0008-0000-0000-000003E84B1C X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 17021415-0009-0000-0000-00001C748DFB Message-Id: <m38tp8n5ol.fsf@oc1027705133.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10432:, , definitions=2017-02-14_09:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 spamscore=0 suspectscore=0 malwarescore=0 phishscore=0 adultscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1612050000 definitions=main-1702140153 X-IsSubscribed: yes |
Commit Message
Andreas Arnez
Feb. 14, 2017, 3:38 p.m. UTC
On Tue, Feb 14 2017, Yao Qi wrote: >> This is fixed by determining the expected value in an >> endianness-independent way. > > This is quite clever, but I don't like it, :) because every time I read it, > it takes me a while what is the test trying to do. Hehe, I see... >> -gdb_test "print/d p\[-1\]" " = 0" >> +# Access the second byte of s through an implicit pointer to the third >> +# byte of s, using a negative offset. Compare that to the second byte of >> +# the short integer 1 in target byte order. >> +gdb_test "p/d p\[-1\] - ((signed char *)(short\[1\]){1})\[1\]" " = 0" >> -- > > Can we check the result of p[-1] explicitly for different endianness? > We can fill in the first two bytes of s with 0x5678, for example, and > it is expected to see different results of p[-1] for different endianness. Sure. See updated patch below. Is this OK then? [Side note: While developing the patch I also found that a slightly different typecast expression -- with the dimension removed from the array typecast -- causes a GDB internal error: (gdb) p ((char*)(short[]){1})[1] /home/arnez/src/binutils-gdb/gdb/gdbtypes.c:4722: internal-error: type* copy_type(const type*): Assertion `TYPE_OBJFILE_OWNED (type)' failed. I see this bug on s390x and amd64, but haven't spent much time investigating it yet.] -- Andreas -- >8 -- Subject: [PATCH v2] Big-endian targets: Fix implptrpiece.exp The test case implptrpiece.exp accesses the second byte of the short integer number 1 and expects it to be zero. This is valid for little-endian targets, but fails on big-endian targets. This is fixed by distinguishing the expected value by endianness. gdb/testsuite/ChangeLog: * gdb.dwarf2/implptrpiece.exp: Fix check for big-endian targets. --- gdb/testsuite/gdb.dwarf2/implptrpiece.exp | 17 +++++++++++++++-- 1 file changed, 15 insertions(+), 2 deletions(-)
Comments
On Tue, Feb 14, 2017 at 3:38 PM, Andreas Arnez <arnez@linux.vnet.ibm.com> wrote: > On Tue, Feb 14 2017, Yao Qi wrote: > >>> This is fixed by determining the expected value in an >>> endianness-independent way. >> >> This is quite clever, but I don't like it, :) because every time I read it, >> it takes me a while what is the test trying to do. > > Hehe, I see... > >>> -gdb_test "print/d p\[-1\]" " = 0" >>> +# Access the second byte of s through an implicit pointer to the third >>> +# byte of s, using a negative offset. Compare that to the second byte of >>> +# the short integer 1 in target byte order. >>> +gdb_test "p/d p\[-1\] - ((signed char *)(short\[1\]){1})\[1\]" " = 0" >>> -- >> >> Can we check the result of p[-1] explicitly for different endianness? >> We can fill in the first two bytes of s with 0x5678, for example, and >> it is expected to see different results of p[-1] for different endianness. > > Sure. See updated patch below. Is this OK then? Yes, patch is OK. > > [Side note: While developing the patch I also found that a slightly > different typecast expression -- with the dimension removed from the > array typecast -- causes a GDB internal error: > > (gdb) p ((char*)(short[]){1})[1] > /home/arnez/src/binutils-gdb/gdb/gdbtypes.c:4722: internal-error: > type* copy_type(const type*): Assertion `TYPE_OBJFILE_OWNED (type)' > failed. > > I see this bug on s390x and amd64, but haven't spent much time > investigating it yet.] Reproduced. Could you file a bug for it?
On Tue, Feb 14 2017, Yao Qi wrote: > On Tue, Feb 14, 2017 at 3:38 PM, Andreas Arnez <arnez@linux.vnet.ibm.com> wrote: [...] >> Sure. See updated patch below. Is this OK then? > > Yes, patch is OK. Thanks, pushed. >> [Side note: While developing the patch I also found that a slightly >> different typecast expression -- with the dimension removed from the >> array typecast -- causes a GDB internal error: >> >> (gdb) p ((char*)(short[]){1})[1] >> /home/arnez/src/binutils-gdb/gdb/gdbtypes.c:4722: internal-error: >> type* copy_type(const type*): Assertion `TYPE_OBJFILE_OWNED (type)' >> failed. >> >> I see this bug on s390x and amd64, but haven't spent much time >> investigating it yet.] > > Reproduced. Could you file a bug for it? Sure: https://sourceware.org/bugzilla/show_bug.cgi?id=21162 -- Andreas
diff --git a/gdb/testsuite/gdb.dwarf2/implptrpiece.exp b/gdb/testsuite/gdb.dwarf2/implptrpiece.exp index af7dd37..ef483c0 100644 --- a/gdb/testsuite/gdb.dwarf2/implptrpiece.exp +++ b/gdb/testsuite/gdb.dwarf2/implptrpiece.exp @@ -80,7 +80,7 @@ Dwarf::assemble $asm_file { {name s} {type :$struct_label} {location { - const1u 1 + const2u 0x5678 stack_value piece 2 const1u 2 @@ -119,4 +119,17 @@ if ![runto_main] { return -1 } -gdb_test "print/d p\[-1\]" " = 0" +# Determine endianness. +set endian "little" +gdb_test_multiple "show endian" "determine endianness" { + -re ".* (big|little) endian.*$gdb_prompt $" { + set endian $expect_out(1,string) + pass "endianness: $endian" + } +} + +# Access the second byte of s through an implicit pointer to the third +# byte of s, using a negative offset. Compare that to the second byte of +# the short integer 0x5678 in target byte order. +switch $endian { little {set val 0x56} big {set val 0x78} } +gdb_test "p/x p\[-1\]" " = $val"