From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id njT+OERe5GIizBwAWB0awg (envelope-from ) for ; Fri, 29 Jul 2022 18:25:08 -0400 Received: by simark.ca (Postfix, from userid 112) id DA2051EA04; Fri, 29 Jul 2022 18:25:08 -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=eMi124vi; 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=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,RDNS_DYNAMIC,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (ip-8-43-85-97.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 591AE1E9EB for ; Fri, 29 Jul 2022 18:25:08 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 359BB384F01A for ; Fri, 29 Jul 2022 22:25:05 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 359BB384F01A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1659133507; bh=QSZQDUe8dXDcDBOok7UuKeMfZaZfUa/Oa+4Ga9q7exg=; 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=eMi124vihay0r0w49H9MEdm1i2uRhFlq79kEXYRqal5/Lcp6VaGnRAf54x0LFA+hg /B4/NNWTM3bOKlmpUDJ3teOga2VgSHDmBqcZ4jq5dUTxEaKUogzXZjySflp29vPVns uUAPpg+DzTy/SbxAwhedAo8LWnTEL8xzbLGoKFKA= Received: from mail-pg1-x529.google.com (mail-pg1-x529.google.com [IPv6:2607:f8b0:4864:20::529]) by sourceware.org (Postfix) with ESMTPS id 1F0C038582A1 for ; Fri, 29 Jul 2022 22:24:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 1F0C038582A1 Received: by mail-pg1-x529.google.com with SMTP id d7so1966385pgc.13 for ; Fri, 29 Jul 2022 15:24:45 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc; bh=QSZQDUe8dXDcDBOok7UuKeMfZaZfUa/Oa+4Ga9q7exg=; b=WJxku5laY4NV93iTHwppCMX7orYfDjiOJQVJQEF86vih+K+lChLxDntnEzq8zrMJfL owXaNDFo2VPlfcX//OQNUQF3HZOrknsvpV3vl+vIISaAQFmUP6i7/L3Jz4wUTGUUFHd8 0uqPc+hkJnxm+7dhbQyYnp0bV+I4TwkrNXKFRKqaa5uEonPpwnu+lIu1tlJPNyp/WGVo Jdg5uG4ILfbJRR2wAsZPt+0E+/qhx6RKINjedyXdBCd9+azGwVwSK3atT2LVnt052sLa 3Zps3lDW7QmKrut/E4wnh4be2J+7DTbrf5Sm8CT/OHUykoPDeAO94kgJ4t08dbdseLDI oynw== X-Gm-Message-State: AJIora8U6PdjizEIDmrC3fsdYPB0reCpbGl2mLfPJJ+dyfG1x5+h8ume soDrDzHf/e8dpWeisYZN1E5f X-Google-Smtp-Source: AGRyM1uO9sOFi1URno+OneW6XRojJRHFVlKDLhia7s4IeCXVuZAArk/sDm7cr661bbXnWhWaq8m0YQ== X-Received: by 2002:a63:d014:0:b0:41a:13b3:69d9 with SMTP id z20-20020a63d014000000b0041a13b369d9mr4459888pgf.202.1659133484000; Fri, 29 Jul 2022 15:24:44 -0700 (PDT) Received: from takamaka.home ([184.69.131.86]) by smtp.gmail.com with ESMTPSA id m8-20020a654c88000000b0040cfb5151fcsm3048614pgt.74.2022.07.29.15.24.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 29 Jul 2022 15:24:43 -0700 (PDT) Received: by takamaka.home (Postfix, from userid 1000) id 79FE0A4AA6; Fri, 29 Jul 2022 15:24:42 -0700 (PDT) Date: Fri, 29 Jul 2022 15:24:42 -0700 To: Tom de Vries Subject: Re: [PATCH][gdb/testsuite] Fix gdb.ada/literals.exp with aarch64 Message-ID: References: <20220727103447.GA9310@delia> <8f343881-a96d-9eef-8cbc-9afc69f97d7d@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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 , gdb-patches@sourceware.org, Joel Brobecker Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" Hi Tom, On Thu, Jul 28, 2022 at 04:21:35PM +0200, Tom de Vries wrote: > On 7/28/22 15:10, Joel Brobecker wrote: > > > > 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. > > > > We're really outside of the Ada language. Would you mind checking > > what the C language does? I think it would make sense to do the same, > > here. E.g., on x86_64-linux, I get: > > > > (gdb) p 0xffffffffffffffff > > $1 = 18446744073709551615 > > > > Ack, that's what the C language does. > > This patch changes gdb to print 18446744073709551615 for ada as well. > > So, pick your favorite patch ;) TomT kindly tested your patch on a number of platforms for us, and everything looked good on those. I propose we go with your second patch which changes the behavior to match what we do in C (I looked at the patch, and it looks good to me, so approved). Thank you! > > Thanks, > - Tom > [gdb/testsuite] Fix gdb.ada/literals.exp with aarch64 > > 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; > ... > > It's not clear why for ada we're using long long for the > fits-in-unsigned-long-long case. > > Fix this by using unsigned long long for the fits-in-unsigned-long-long case, > meaning the new reference output is 18446744073709551615 instead of -1. > > Tested on x86_64-linux. > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29416 > > --- > gdb/ada-lex.l | 4 ++-- > gdb/testsuite/gdb.ada/literals.exp | 2 +- > 2 files changed, 3 insertions(+), 3 deletions(-) > > diff --git a/gdb/ada-lex.l b/gdb/ada-lex.l > index 002eb811e41..ed88d502e9f 100644 > --- a/gdb/ada-lex.l > +++ b/gdb/ada-lex.l > @@ -498,8 +498,8 @@ processInt (struct parser_state *par_state, const char *base0, > yylval.typed_val.type = type_long_long (par_state); > else if (fits_in_type (1, value, long_long_bits, false)) > { > - /* Note: Interprets ULLONG_MAX as -1. */ > - yylval.typed_val.type = type_long_long (par_state); > + yylval.typed_val.type > + = builtin_type (par_state->gdbarch ())->builtin_unsigned_long_long; > /* See unsigned long case above. */ > if (value & LONGEST_SIGN) > yylval.typed_val.val = > diff --git a/gdb/testsuite/gdb.ada/literals.exp b/gdb/testsuite/gdb.ada/literals.exp > index a6ac89b540f..6badc857292 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#" " = 18446744073709551615" -- Joel