From patchwork Tue Feb 14 15:38:34 2017 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Andreas Arnez X-Patchwork-Id: 19257 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: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , 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 ; 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 ; 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 from ; 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 To: Yao Qi Cc: "gdb-patches\@sourceware.org" Subject: Re: [PATCH] Big-endian targets: Fix implptrpiece.exp References: Date: Tue, 14 Feb 2017 16:38:34 +0100 In-Reply-To: (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 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: 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 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(-) 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"