Message ID | 20221130140006.25890-1-tdevries@suse.de |
---|---|
State | Committed |
Headers |
Return-Path: <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> X-Original-To: patchwork@sourceware.org Delivered-To: patchwork@sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 491A83858D1E for <patchwork@sourceware.org>; Wed, 30 Nov 2022 14:00:30 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 491A83858D1E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1669816830; bh=aWcu9PVHnwvhX7/I4pt6DJnxFIce7XK+rF9cN+rGrG4=; h=To:Cc:Subject:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=jFGIe66us/MTh+ZdpuHP/9H7cCOkBkUHgBrNC+ntVLWhRw/Y3zEJ6KnZppNqikvz+ fV82bTqMA1gQvVcU3GH8ZD3iC9ZD/fAyDZx0ST6ec1CjtInG6M/2V3Ycsl55levCo5 zFTtsmg25yRTEuCk5o0KXN+zzuCCv7mDYlV53ov8= X-Original-To: gdb-patches@sourceware.org Delivered-To: gdb-patches@sourceware.org Received: from smtp-out2.suse.de (smtp-out2.suse.de [195.135.220.29]) by sourceware.org (Postfix) with ESMTPS id 365073858D1E for <gdb-patches@sourceware.org>; Wed, 30 Nov 2022 14:00:08 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 365073858D1E 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-out2.suse.de (Postfix) with ESMTPS id 695031FD6B; Wed, 30 Nov 2022 14:00:07 +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 4FFA513A70; Wed, 30 Nov 2022 14:00:07 +0000 (UTC) Received: from dovecot-director2.suse.de ([192.168.254.65]) by imap2.suse-dmz.suse.de with ESMTPSA id wUuBEudhh2NecAAAMHmgww (envelope-from <tdevries@suse.de>); Wed, 30 Nov 2022 14:00:07 +0000 To: gdb-patches@sourceware.org Cc: Carl Love <cel@us.ibm.com>, Ulrich Weigand <Ulrich.Weigand@de.ibm.com> Subject: [PATCH] [gdb/testsuite] Fix gdb.ada/float-bits.exp for powerpc64le Date: Wed, 30 Nov 2022 15:00:06 +0100 Message-Id: <20221130140006.25890-1-tdevries@suse.de> X-Mailer: git-send-email 2.35.3 MIME-Version: 1.0 Content-Transfer-Encoding: 8bit X-Spam-Status: No, score=-12.6 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, 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 <gdb-patches.sourceware.org> List-Unsubscribe: <https://sourceware.org/mailman/options/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=unsubscribe> List-Archive: <https://sourceware.org/pipermail/gdb-patches/> List-Post: <mailto:gdb-patches@sourceware.org> List-Help: <mailto:gdb-patches-request@sourceware.org?subject=help> List-Subscribe: <https://sourceware.org/mailman/listinfo/gdb-patches>, <mailto:gdb-patches-request@sourceware.org?subject=subscribe> From: Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> Reply-To: Tom de Vries <tdevries@suse.de> Errors-To: gdb-patches-bounces+patchwork=sourceware.org@sourceware.org Sender: "Gdb-patches" <gdb-patches-bounces+patchwork=sourceware.org@sourceware.org> |
Series |
[gdb/testsuite] Fix gdb.ada/float-bits.exp for powerpc64le
|
|
Commit Message
Tom de Vries
Nov. 30, 2022, 2 p.m. UTC
On powerpc64le-linux, I run into: ... (gdb) print 16llf#4000921fb54442d18469898cc51701b8#^M $9 = <invalid float value>^M (gdb) FAIL: gdb.ada/float-bits.exp: print \ 16llf#4000921fb54442d18469898cc51701b8# ... The problem is that we're using a hex string for the 128-bit IEEE quad long double format, but the actual long double float format is: ... gdbarch_dump: long_double_format = floatformat_ibm_long_double_little^M ... Fix this by using the hex string obtained by compiling test.c: ... long double a = 5.0e+25L; ... like so: ... $ gcc -mlittle test.c -c -g ... and running gdb: ... $ gdb -q -batch test.o -ex "p /x a" $1 = 0xc1e1c000000000004544adf4b7320335 ... and likewise for -mbig: ... $ gdb -q -batch test.o -ex "p /x a" $1 = 0x4544adf4b7320335c1e1c00000000000 ... Tested on powerpc64le-linux. I excercised the case of floatformat_ibm_long_double_big by using "set endian big" in the test-case. Note that for this patch to work correctly, recent commit aaa79cd62b8 ("[gdb] Improve printing of float formats") is required. PR testsuite/29816 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29816 --- gdb/testsuite/gdb.ada/float-bits.exp | 28 ++++++++++++++++++++++++++++ 1 file changed, 28 insertions(+) base-commit: aaa79cd62b873be672e3163eb267513c97ec4399
Comments
>>>>> "Tom" == Tom de Vries via Gdb-patches <gdb-patches@sourceware.org> writes:
Tom> I excercised the case of floatformat_ibm_long_double_big by
Tom> using "set endian big" in the test-case.
Tom> Note that for this patch to work correctly, recent commit aaa79cd62b8 ("[gdb]
Tom> Improve printing of float formats") is required.
Tom> PR testsuite/29816
Tom> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29816
Thanks for doing this.
This looks ok to me.
Tom
Tom: On Wed, 2022-11-30 at 15:00 +0100, Tom de Vries wrote: > On powerpc64le-linux, I run into: > ... > (gdb) print 16llf#4000921fb54442d18469898cc51701b8#^M > $9 = <invalid float value>^M > (gdb) FAIL: gdb.ada/float-bits.exp: print \ > 16llf#4000921fb54442d18469898cc51701b8# > ... > > The problem is that we're using a hex string for the 128-bit IEEE > quad long > double format, but the actual long double float format is: > ... > gdbarch_dump: long_double_format = > floatformat_ibm_long_double_little^M > ... I am not sure what exactly the defaults are for the ada compiler. But for GCC compiling C code, the default was floatformat_ibm_long_double_little until recently. The default setting for C was changed to IEEE. Not sure exactly what the version was. I will have to check. Not sure if ada will switch or not. Carl > > Fix this by using the hex string obtained by compiling test.c: > ... > long double a = 5.0e+25L; > ... > like so: > ... > $ gcc -mlittle test.c -c -g > ... > and running gdb: > ... > $ gdb -q -batch test.o -ex "p /x a" > $1 = 0xc1e1c000000000004544adf4b7320335 > ... > and likewise for -mbig: > ... > $ gdb -q -batch test.o -ex "p /x a" > $1 = 0x4544adf4b7320335c1e1c00000000000 > ... > > Tested on powerpc64le-linux. > > I excercised the case of floatformat_ibm_long_double_big by > using "set endian big" in the test-case. > > Note that for this patch to work correctly, recent commit aaa79cd62b8 > ("[gdb] > Improve printing of float formats") is required. > > PR testsuite/29816 > Bug: > https://sourceware.org/bugzilla/show_bug.cgi?id=29816 > > --- > gdb/testsuite/gdb.ada/float-bits.exp | 28 > ++++++++++++++++++++++++++++ > 1 file changed, 28 insertions(+) > > diff --git a/gdb/testsuite/gdb.ada/float-bits.exp > b/gdb/testsuite/gdb.ada/float-bits.exp > index 55a0566580c..921fe36a4bd 100644 > --- a/gdb/testsuite/gdb.ada/float-bits.exp > +++ b/gdb/testsuite/gdb.ada/float-bits.exp > @@ -73,12 +73,40 @@ set gdb_long_double_size [float_size "16llf#0#" ] > # example, IEEE quad versus i387 long doubles. Account for that in > the > # tests below. > > +# Get the used long double format. > +set long_double_format "" > +gdb_test_multiple "maint print architecture" "" { > + -re "\r\ngdbarch_dump: long_double_format = (\[^\r\n\]*)" { > + set long_double_format $expect_out(1,string) > + exp_continue > + } > + -re -wrap "" { > + pass $gdb_test_name > + } > +} > + > # Set default values for 128-bit IEEE quad long doubles. > set valid_long_double "16llf#4000921fb54442d18469898cc51701b8#" > set printed_long_double "3.1415926535897932384626433832795028" > set invalid_long_double "" > set has_invalid_long_double 0 > > +switch -glob $long_double_format { > + floatformat_ibm_long_double_* { > + set w1 c1e1c00000000000 > + set w2 4544adf4b7320335 > + switch $long_double_format { > + floatformat_ibm_long_double_big { > + set valid_long_double "16llf#$w2$w1#" > + } > + floatformat_ibm_long_double_little { > + set valid_long_double "16llf#$w1$w2#" > + } > + } > + set printed_long_double "50000000000000000000000000.0" > + } > +} > + > if { [istarget x86_64-*-* ] || [istarget i?86-*-*] } { > # i387 long double have invalid values > set has_invalid_long_double 1 > > base-commit: aaa79cd62b873be672e3163eb267513c97ec4399
This change seems to be causing a timeout on aarch64-linux Ubuntu 22.04. FAIL: gdb.ada/float-bits.exp: maint print architecture (timeout) # of expected passes 12 # of unexpected failures 1 It is as if the listing of the architecture fields didn't have time to finish. On 11/30/22 14:00, Tom de Vries via Gdb-patches wrote: > On powerpc64le-linux, I run into: > ... > (gdb) print 16llf#4000921fb54442d18469898cc51701b8#^M > $9 = <invalid float value>^M > (gdb) FAIL: gdb.ada/float-bits.exp: print \ > 16llf#4000921fb54442d18469898cc51701b8# > ... > > The problem is that we're using a hex string for the 128-bit IEEE quad long > double format, but the actual long double float format is: > ... > gdbarch_dump: long_double_format = floatformat_ibm_long_double_little^M > ... > > Fix this by using the hex string obtained by compiling test.c: > ... > long double a = 5.0e+25L; > ... > like so: > ... > $ gcc -mlittle test.c -c -g > ... > and running gdb: > ... > $ gdb -q -batch test.o -ex "p /x a" > $1 = 0xc1e1c000000000004544adf4b7320335 > ... > and likewise for -mbig: > ... > $ gdb -q -batch test.o -ex "p /x a" > $1 = 0x4544adf4b7320335c1e1c00000000000 > ... > > Tested on powerpc64le-linux. > > I excercised the case of floatformat_ibm_long_double_big by > using "set endian big" in the test-case. > > Note that for this patch to work correctly, recent commit aaa79cd62b8 ("[gdb] > Improve printing of float formats") is required. > > PR testsuite/29816 > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=29816 > --- > gdb/testsuite/gdb.ada/float-bits.exp | 28 ++++++++++++++++++++++++++++ > 1 file changed, 28 insertions(+) > > diff --git a/gdb/testsuite/gdb.ada/float-bits.exp b/gdb/testsuite/gdb.ada/float-bits.exp > index 55a0566580c..921fe36a4bd 100644 > --- a/gdb/testsuite/gdb.ada/float-bits.exp > +++ b/gdb/testsuite/gdb.ada/float-bits.exp > @@ -73,12 +73,40 @@ set gdb_long_double_size [float_size "16llf#0#" ] > # example, IEEE quad versus i387 long doubles. Account for that in the > # tests below. > > +# Get the used long double format. > +set long_double_format "" > +gdb_test_multiple "maint print architecture" "" { > + -re "\r\ngdbarch_dump: long_double_format = (\[^\r\n\]*)" { > + set long_double_format $expect_out(1,string) > + exp_continue > + } > + -re -wrap "" { > + pass $gdb_test_name > + } > +} > + > # Set default values for 128-bit IEEE quad long doubles. > set valid_long_double "16llf#4000921fb54442d18469898cc51701b8#" > set printed_long_double "3.1415926535897932384626433832795028" > set invalid_long_double "" > set has_invalid_long_double 0 > > +switch -glob $long_double_format { > + floatformat_ibm_long_double_* { > + set w1 c1e1c00000000000 > + set w2 4544adf4b7320335 > + switch $long_double_format { > + floatformat_ibm_long_double_big { > + set valid_long_double "16llf#$w2$w1#" > + } > + floatformat_ibm_long_double_little { > + set valid_long_double "16llf#$w1$w2#" > + } > + } > + set printed_long_double "50000000000000000000000000.0" > + } > +} > + > if { [istarget x86_64-*-* ] || [istarget i?86-*-*] } { > # i387 long double have invalid values > set has_invalid_long_double 1 > > base-commit: aaa79cd62b873be672e3163eb267513c97ec4399
On 12/1/22 14:49, Luis Machado wrote: > This change seems to be causing a timeout on aarch64-linux Ubuntu 22.04. > > FAIL: gdb.ada/float-bits.exp: maint print architecture (timeout) > > # of expected passes 12 > # of unexpected failures 1 > > It is as if the listing of the architecture fields didn't have time to > finish. > Can you see if this fixes things? Thanks, - Tom
On 12/1/22 14:40, Tom de Vries wrote: > On 12/1/22 14:49, Luis Machado wrote: >> This change seems to be causing a timeout on aarch64-linux Ubuntu 22.04. >> >> FAIL: gdb.ada/float-bits.exp: maint print architecture (timeout) >> >> # of expected passes 12 >> # of unexpected failures 1 >> >> It is as if the listing of the architecture fields didn't have time to finish. >> > > Can you see if this fixes things? > > Thanks, > - Tom I checked the patch and it doesn't seem to help. It still times out. I briefly investigated this and it looks like a (gdb) prompt gets output when it shouldn't. gdbarch_dump: read_core_file_mappings = <0xaaaac98fb7f0> (gdb) aarch64_dump_tdep: Lowest pc = 0x0x8000 <the prompt is here, hitting enter gives another prompt below) (gdb) This doesn't seem to be related to your patch, but something else.
On 12/1/22 20:51, Luis Machado wrote: > On 12/1/22 14:40, Tom de Vries wrote: >> On 12/1/22 14:49, Luis Machado wrote: >>> This change seems to be causing a timeout on aarch64-linux Ubuntu 22.04. >>> >>> FAIL: gdb.ada/float-bits.exp: maint print architecture (timeout) >>> >>> # of expected passes 12 >>> # of unexpected failures 1 >>> >>> It is as if the listing of the architecture fields didn't have time to finish. >>> >> >> Can you see if this fixes things? >> >> Thanks, >> - Tom > > I checked the patch and it doesn't seem to help. It still times out. > > I briefly investigated this and it looks like a (gdb) prompt gets output when it shouldn't. > > gdbarch_dump: read_core_file_mappings = <0xaaaac98fb7f0> > (gdb) aarch64_dump_tdep: Lowest pc = 0x0x8000 <the prompt is here, hitting enter gives another prompt below) > (gdb) > > This doesn't seem to be related to your patch, but something else. Ah, the tdep dumper for aarch64 is missing a "\n"! So the prompt seems to be output in the beginning of the same line. Odd, and slightly fragile. In any case, this is easily fixed with the \n addition. I'll push an obvious change for that. Sorry for the noise.
On 12/1/22 22:01, Luis Machado wrote: > On 12/1/22 20:51, Luis Machado wrote: >> On 12/1/22 14:40, Tom de Vries wrote: >>> On 12/1/22 14:49, Luis Machado wrote: >>>> This change seems to be causing a timeout on aarch64-linux Ubuntu >>>> 22.04. >>>> >>>> FAIL: gdb.ada/float-bits.exp: maint print architecture (timeout) >>>> >>>> # of expected passes 12 >>>> # of unexpected failures 1 >>>> >>>> It is as if the listing of the architecture fields didn't have time >>>> to finish. >>>> >>> >>> Can you see if this fixes things? >>> >>> Thanks, >>> - Tom >> >> I checked the patch and it doesn't seem to help. It still times out. >> >> I briefly investigated this and it looks like a (gdb) prompt gets >> output when it shouldn't. >> >> gdbarch_dump: read_core_file_mappings = <0xaaaac98fb7f0> >> (gdb) aarch64_dump_tdep: Lowest pc = 0x0x8000 <the prompt is here, >> hitting enter gives another prompt below) >> (gdb) >> >> This doesn't seem to be related to your patch, but something else. > > Ah, the tdep dumper for aarch64 is missing a "\n"! So the prompt seems > to be output in the beginning of the same line. > > Odd, and slightly fragile. > > In any case, this is easily fixed with the \n addition. I'll push an > obvious change for that. > > Sorry for the noise. No problem :) Now that I've done the work anyway, I've pushed the line-by-line reading patch with an updated commit message ( https://sourceware.org/pipermail/gdb-patches/2022-December/194408.html ). Thanks, - Tom
diff --git a/gdb/testsuite/gdb.ada/float-bits.exp b/gdb/testsuite/gdb.ada/float-bits.exp index 55a0566580c..921fe36a4bd 100644 --- a/gdb/testsuite/gdb.ada/float-bits.exp +++ b/gdb/testsuite/gdb.ada/float-bits.exp @@ -73,12 +73,40 @@ set gdb_long_double_size [float_size "16llf#0#" ] # example, IEEE quad versus i387 long doubles. Account for that in the # tests below. +# Get the used long double format. +set long_double_format "" +gdb_test_multiple "maint print architecture" "" { + -re "\r\ngdbarch_dump: long_double_format = (\[^\r\n\]*)" { + set long_double_format $expect_out(1,string) + exp_continue + } + -re -wrap "" { + pass $gdb_test_name + } +} + # Set default values for 128-bit IEEE quad long doubles. set valid_long_double "16llf#4000921fb54442d18469898cc51701b8#" set printed_long_double "3.1415926535897932384626433832795028" set invalid_long_double "" set has_invalid_long_double 0 +switch -glob $long_double_format { + floatformat_ibm_long_double_* { + set w1 c1e1c00000000000 + set w2 4544adf4b7320335 + switch $long_double_format { + floatformat_ibm_long_double_big { + set valid_long_double "16llf#$w2$w1#" + } + floatformat_ibm_long_double_little { + set valid_long_double "16llf#$w1$w2#" + } + } + set printed_long_double "50000000000000000000000000.0" + } +} + if { [istarget x86_64-*-* ] || [istarget i?86-*-*] } { # i387 long double have invalid values set has_invalid_long_double 1