From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id sFbYF8tw4WI+hBsAWB0awg (envelope-from ) for ; Wed, 27 Jul 2022 13:07:23 -0400 Received: by simark.ca (Postfix, from userid 112) id 533E81E9ED; Wed, 27 Jul 2022 13:07:23 -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=cO+MgGxs; 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=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,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 D79C91E87E for ; Wed, 27 Jul 2022 13:07:22 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 35420385AC2F for ; Wed, 27 Jul 2022 17:07:22 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 35420385AC2F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1658941642; bh=cXLEiS0XMmJ4OupSLqWn8vTLOxUhVIYIYs5i2Mr7H7E=; h=Date:To:Subject:References:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=cO+MgGxsWN19Nd2i2uEmUVBxplnVD0hfyVarCD50eSi3xYl9+pa3v47dPmqrCL8V9 9WOqdBU3QfzMZkmsOQOUwKrDWz2orr+86K6Qd/P7Q3i2IoWId5ATcfTuYOwy04BFpQ wnOWi6nO1kluQWU3sSmFmmWWB/qo5ZKvGDlmz+50= 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 To: Tom de Vries 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-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: Joel Brobecker via Gdb-patches Reply-To: Joel Brobecker Cc: Tom Tromey , Joel Brobecker , gdb-patches@sourceware.org Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" 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