From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id vdPaJ0ao4WIVmRsAWB0awg (envelope-from ) for ; Wed, 27 Jul 2022 17:04:06 -0400 Received: by simark.ca (Postfix, from userid 112) id 91EA81E9ED; Wed, 27 Jul 2022 17:04:06 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=mClYTW5p; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-4.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,NICE_REPLY_A,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 131AD1E87E for ; Wed, 27 Jul 2022 17:04:06 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 288AA385AE40 for ; Wed, 27 Jul 2022 21:04:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 288AA385AE40 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1658955845; bh=vN/TL3LKBZB73MGnLN+ifR6SS8MIMQHVYRtkV6RdpV0=; h=Date:Subject:To:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=mClYTW5p87QepxrQeqoC8QUkDGDYwadw8ro7cQW0lHDRT1SlOi84D5g7N7VLlCPSA V+KeAjR9kwTu8k9tpf/tXeLG1bRzEsCUphth34phM4TB5xGlWvkJQ2jS9aXoNdyWwr c6yuybSr68mhNLyYtZHySPU2kf0Ja/HK5X/D2q9c= Received: from smtp-out1.suse.de (smtp-out1.suse.de [195.135.220.28]) by sourceware.org (Postfix) with ESMTPS id A4EBC385829F for ; Wed, 27 Jul 2022 21:03:44 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A4EBC385829F Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by smtp-out1.suse.de (Postfix) with ESMTPS id 7CE7F3F10F; Wed, 27 Jul 2022 21:03:43 +0000 (UTC) Received: from imap2.suse-dmz.suse.de (imap2.suse-dmz.suse.de [192.168.254.74]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (P-521) server-digest SHA512) (No client certificate requested) by imap2.suse-dmz.suse.de (Postfix) with ESMTPS id 5458413ABC; Wed, 27 Jul 2022 21:03:43 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id k/9LEy+o4WI7aAAAMHmgww (envelope-from ); Wed, 27 Jul 2022 21:03:43 +0000 Message-ID: <8f343881-a96d-9eef-8cbc-9afc69f97d7d@suse.de> Date: Wed, 27 Jul 2022 23:03:42 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101 Thunderbird/91.9.0 Subject: Re: [PATCH][gdb/testsuite] Fix gdb.ada/literals.exp with aarch64 Content-Language: en-US To: Joel Brobecker References: <20220727103447.GA9310@delia> In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit 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: , From: Tom de Vries via Gdb-patches Reply-To: Tom de Vries Cc: Tom Tromey , gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On 7/27/22 19:06, Joel Brobecker wrote: > Hi Tom, > >> On aarch64-linux, I run into: >> ... >> (gdb) print 16#ffffffffffffffff#^M >> $7 = 18446744073709551615^M >> (gdb) FAIL: gdb.ada/literals.exp: print 16#ffffffffffffffff# >> ... >> while on x86_64-linux instead, I get: >> ... >> (gdb) print 16#ffffffffffffffff#^M >> $7 = -1^M >> (gdb) PASS: gdb.ada/literals.exp: print 16#ffffffffffffffff# >> ... >> >> We can easily reproduce this on x86_64-linux using: >> ... >> $ gdb -q -batch -ex "set lang ada" -ex "set arch i386" \ >> -ex "print 16#ffffffffffffffff#" >> $1 = -1 >> $ gdb -q -batch -ex "set lang ada" -ex "set arch aarch64" \ >> -ex "print 16#ffffffffffffffff#" >> $1 = 18446744073709551615 >> ... >> >> With i386, we have: >> ... >> (gdb) p int_bits >> $3 = 32 >> (gdb) p long_bits >> $4 = 32 >> (gdb) p long_long_bits >> $5 = 64 >> ... >> and so in processInt we hit the fits-in-unsigned-long-long case where we use >> as type long long: >> ... >> /* Note: Interprets ULLONG_MAX as -1. */ >> yylval.typed_val.type = type_long_long (par_state); >> ... >> >> With aarch64, we have instead: >> ... >> (gdb) p int_bits >> $1 = 32 >> (gdb) p long_bits >> $2 = 64 >> (gdb) p long_long_bits >> $3 = 64 >> ... >> and so in processInt we hit the fits-in-unsigned-long case where we use >> as type unsigned long: >> ... >> yylval.typed_val.type >> = builtin_type (par_state->gdbarch ())->builtin_unsigned_long; >> ... >> >> Fix this by updating the test-case to accept 18446744073709551615 as well. >> >> Tested on x86_64-linux and aarch64-linux. >> >> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29416 >> >> Any comments? > > Thanks for the patch. > > My question is whether it actually makes sense that -1 be > a valid output for the print command above. I tried the addition > of ... > > | /* Note: Interprets ULLONG_MAX as -1. */ > | yylval.typed_val.type = type_long_long (par_state); > > ... to a patch of yours: > > | commit ac3afe36d73c84096685fece885d70b28bc9629f > | Author: Tom de Vries > | Date: Sat Jun 4 13:17:33 2022 +0200 > | Subject: [gdb/ada] Fix literal truncation > | > | Make sure we error out on overflow instead of truncating in all cases. > | > | Tested on x86_64-linux, with a build with --enable-targets=all. > > Do you remember why we do this? Intuitively, you'd expect that GDB > would behave the same regardless of whether it selects type "long" > or "long long" for its processing, as long as both types are 64-bit. > I have no idea. AFAICT it's been in gdb since the "Add base ada language files" commit from 2002 that we avoid "unsigned long long". I've taken care to preserve the behaviour in the commit you refer to (and this patch), since I don't have the knowledge to decide that things should be different. > With the above, we can take this patch as an intermediate remedy, > but I think we might need to dig deeper into why we use a signed > type in the case of long long but not long, particularly when both > types are the same size. > > WDYT? > I'd be happy to write a patch to change the behaviour of gdb. But somebody knowledgeable in Ada needs to specify what that needs to be. Thanks, - Tom >> --- >> gdb/testsuite/gdb.ada/literals.exp | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/gdb/testsuite/gdb.ada/literals.exp b/gdb/testsuite/gdb.ada/literals.exp >> index a6ac89b540f..744a6bc573c 100644 >> --- a/gdb/testsuite/gdb.ada/literals.exp >> +++ b/gdb/testsuite/gdb.ada/literals.exp >> @@ -36,4 +36,4 @@ gdb_test "print 16#f#e1" " = 240" >> gdb_test "print 16#1#e10" " = 1099511627776" >> >> gdb_test "print/x 16#7fffffffffffffff#" " = 0x7fffffffffffffff" >> -gdb_test "print 16#ffffffffffffffff#" " = -1" >> +gdb_test "print 16#ffffffffffffffff#" " = (-1|18446744073709551615)" >