From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-x629.google.com (mail-pl1-x629.google.com [IPv6:2607:f8b0:4864:20::629]) by sourceware.org (Postfix) with ESMTPS id 735073857033 for ; Wed, 27 Jul 2022 17:07:00 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 735073857033 Received: by mail-pl1-x629.google.com with SMTP id x1so14846738plb.3 for ; Wed, 27 Jul 2022 10:07:00 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=cXLEiS0XMmJ4OupSLqWn8vTLOxUhVIYIYs5i2Mr7H7E=; b=DBtQRHVlTacuHcxoBRcYMUpD6aLIBHHQGh6+PK+LpJxA7v5h/zGK2DVLNHSMaGjZoP PphtemDwwB8lVetsZCgj5EF/QHriIqFENEGK4zffgYEGsasSc1t65vgUay3oDP6g2zm2 Tu8ExjXoMP1j4WymMzdrRyJ/5FrAwNSHOzSaQyVV7isv6STxJ/LTk91vM60elAANjzB4 Ee7EgSNSKBOqDQsUHNpmw7OHuTJ+jgPrv6RjrEN41ca8FP4vXr4dKjTvOZATCTNBUpE5 G4EmLVgYynUYEi0iimpyYwrbz7YvrZ5W9VmlzVn7/fi7UG2i/mf1dIyKfbYxdJFvJ/lm 4gAw== X-Gm-Message-State: AJIora+/9L4qw5r5XInj7bQ9OcLuyiBWyzniGpqlGclZnl3Gr6/CeoP0 QqTEqh77C4CTH8MjvBp9W8/z X-Google-Smtp-Source: AGRyM1utR5CpkVZ9k2phNbP7iiuozwfuhuk4h5eEkpXuPN8PRFUijV9bs+ddS/1EgPZji87OX8/SUQ== X-Received: by 2002:a17:902:dacb:b0:16d:7c59:bcf6 with SMTP id q11-20020a170902dacb00b0016d7c59bcf6mr13728373plx.135.1658941619401; Wed, 27 Jul 2022 10:06:59 -0700 (PDT) Received: from takamaka.home ([184.69.131.86]) by smtp.gmail.com with ESMTPSA id om2-20020a17090b3a8200b001f209699d89sm2125419pjb.18.2022.07.27.10.06.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 27 Jul 2022 10:06:58 -0700 (PDT) Received: by takamaka.home (Postfix, from userid 1000) id 06C0BA4AA6; Wed, 27 Jul 2022 10:06:58 -0700 (PDT) Date: Wed, 27 Jul 2022 10:06:58 -0700 From: Joel Brobecker To: Tom de Vries Cc: gdb-patches@sourceware.org, Tom Tromey , Joel Brobecker , Luis Machado , Joel Brobecker Subject: Re: [PATCH][gdb/testsuite] Fix gdb.ada/literals.exp with aarch64 Message-ID: References: <20220727103447.GA9310@delia> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20220727103447.GA9310@delia> X-Spam-Status: No, score=-10.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, KAM_NUMSUBJECT, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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, 27 Jul 2022 17:07:04 -0000 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. 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? > --- > 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)" -- Joel