From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id EF8C73858406 for ; Wed, 12 Jan 2022 17:14:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org EF8C73858406 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 20CHEO37003161 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Wed, 12 Jan 2022 12:14:29 -0500 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 20CHEO37003161 Received: from [10.0.0.11] (192-222-157-6.qc.cable.ebox.net [192.222.157.6]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPSA id E088E1EA69; Wed, 12 Jan 2022 12:14:23 -0500 (EST) Message-ID: <8575c2bd-f33a-ef00-f1df-5934945ef2a1@polymtl.ca> Date: Wed, 12 Jan 2022 12:14:23 -0500 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.4.0 Subject: Re: [PATCH 1/2] gdb: testsuite: fix failed testcases in gdb.base/charset.exp Content-Language: en-US To: Tiezhu Yang , gdb-patches@sourceware.org References: <20211225040320.8467-1-yangtiezhu@loongson.cn> <20211225040320.8467-2-yangtiezhu@loongson.cn> <29468082-9c93-b644-199f-784c992ec369@loongson.cn> <3e2cf983-d7ca-d8a5-db94-f0e5468fa0ba@polymtl.ca> <2acf4993-06aa-0ad0-b984-f195ddeb766f@loongson.cn> From: Simon Marchi In-Reply-To: <2acf4993-06aa-0ad0-b984-f195ddeb766f@loongson.cn> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Wed, 12 Jan 2022 17:14:24 +0000 X-Spam-Status: No, score=-4.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 12 Jan 2022 17:14:38 -0000 On 2022-01-12 06:31, Tiezhu Yang wrote: > > > On 1/12/22 12:28, Simon Marchi wrote: >> >> >> On 2022-01-09 22:23, Tiezhu Yang wrote: >>> >>> >>> On 1/10/22 10:42, Simon Marchi wrote: >>>> >>>> >>>> On 2021-12-24 23:03, Tiezhu Yang wrote: >>>>> In gdb/testsuite/gdb.base/charset.c, the last argument is greater than 127 >>>>> when call fill_run() in EBCDIC-US and IBM1047, but the type of string[] is >>>>> char, this will change the value due to sign extension. >>>>> >>>>> For example, ebcdic_us_string[7] will be -63 instead of the original 193 in >>>>> EBCDIC-US. >>>>> >>>>> Make the type of string[] as unsigned char to fix the following six failed >>>>> testcases: >>>>> >>>>> $ grep FAIL gdb/testsuite/gdb.sum >>>>> FAIL: gdb.base/charset.exp: check value of parsed character literal in EBCDIC-US >>>>> FAIL: gdb.base/charset.exp: check value of parsed string literal in EBCDIC-US >>>>> FAIL: gdb.base/charset.exp: check value of escape that doesn't exist in EBCDIC-US >>>>> FAIL: gdb.base/charset.exp: check value of parsed character literal in IBM1047 >>>>> FAIL: gdb.base/charset.exp: check value of parsed string literal in IBM1047 >>>>> FAIL: gdb.base/charset.exp: check value of escape that doesn't exist in IBM1047 >>>> >>>> Out of curiosity, on which configuration do you see these failures? >> >> Hmm, I now see these failures on an x86-64 Linux (Ubuntu 20.04) machine: >> >> FAIL: gdb.base/charset.exp: check value of parsed character literal in EBCDIC-US >> FAIL: gdb.base/charset.exp: check value of parsed string literal in EBCDIC-US >> FAIL: gdb.base/charset.exp: check value of escape that doesn't exist in EBCDIC-US >> FAIL: gdb.base/charset.exp: check value of parsed character literal in IBM1047 >> FAIL: gdb.base/charset.exp: check value of parsed string literal in IBM1047 >> FAIL: gdb.base/charset.exp: check value of escape that doesn't exist in IBM1047 >> >> The first FAIL looks like: >> >> 444 print /d 'A' == ebcdic_us_string[7]^M >> 445 $63 = 0^M >> 446 (gdb) FAIL: gdb.base/charset.exp: check value of parsed character literal in EBCDIC-US >> >> Could you give it a test on x86-64? > > On x86-64: > > (gdb) set target-charset EBCDIC-US > (gdb) print 'A' > $1 = -63 'A' > > On LoongArch: > > (gdb) set target-charset EBCDIC-US > (gdb) print 'A' > $1 = 193 'A' > > In gdb/testsuite/gdb.base/charset.c, the original > ebcdic_us_string[7] is 193, > (1) if string[] type is signed, it will change 193 to -63. > (2) if string[] type is unsigned, it will keep it as 193. > > According to the official doc, 'A' is 193 in EBCDIC. > https://www.ibm.com/docs/en/zos/2.1.0?topic=sequences-ebcdic > > So it seems that there exists some issues when > set target-charset EBCDIC-US > on x86-64? Ok, so 'A' yields a "char". It's signed on x86-64 because "char" is signed on x86-64. So the expression `'A' == ebcdic_us_string[7]` compares the signed char with bits 0xc1 with the unsigned char with bits 0xc1. This little program shows 0 on x86-64: ~~~ #include int main() { char c1 = -63; unsigned char c2 = 193; printf("%d\n", c1 == c2); return 0; } ~~~ On AArch64, where char is unsigned by default, it shows 1. I don't really see the problem with the original test code, to be honest. On an architecture where char is signed, then both 'A' and ebcdic_us_string[7] will yield -63, which makes the equality true. On an architecture where char is unsigned, then both 'A' and ebcdic_us_string[7] will yield 193, which also makes the equality true. An interesting thing is that the test did pass on AArch64 (which has char unsigned like LoongArch) before your patch. Can you investigate why? Simon