[PATCH] [gdb/testsuite] Fix gdb.ada/float-bits.exp for powerpc64le

[PATCH] [gdb/testsuite] Fix gdb.ada/float-bits.exp for powerpc64le

[Tom de Vries]

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
-- 
2.35.3

Re: [PATCH] [gdb/testsuite] Fix gdb.ada/float-bits.exp for powerpc64le

[Tom Tromey]

>>>>> "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

Re: [PATCH] [gdb/testsuite] Fix gdb.ada/float-bits.exp for powerpc64le

[Carl Love]

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

Re: [PATCH] [gdb/testsuite] Fix gdb.ada/float-bits.exp for powerpc64le

[Luis Machado]

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

Re: [PATCH] [gdb/testsuite] Fix gdb.ada/float-bits.exp for powerpc64le

[Tom de Vries]

[-- Attachment #1: Type: text/plain, Size: 417 bytes --]

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

[-- Attachment #2: 0001-gdb-testsuite-Fix-timeout-in-gdb.ada-float-bits.exp.patch --]
[-- Type: text/x-patch, Size: 1628 bytes --]

From a2c476bbc9fde2e661c035cb2c1e460da5bbee49 Mon Sep 17 00:00:00 2001
From: Tom de Vries <tdevries@suse.de>
Date: Thu, 1 Dec 2022 15:28:48 +0100
Subject: [PATCH] [gdb/testsuite] Fix timeout in gdb.ada/float-bits.exp

A timeout was reported:
...
FAIL: gdb.ada/float-bits.exp: maint print architecture (timeout)
...
after recent commit 32a5aa26256 ("[gdb/testsuite] Fix gdb.ada/float-bits.exp
for powerpc64le").

Fix this by rewriting the gdb_test_multiple to read line-by-line.

Tested on x86_64-linux.
---
 gdb/testsuite/gdb.ada/float-bits.exp | 13 ++++++++++---
 1 file changed, 10 insertions(+), 3 deletions(-)

diff --git a/gdb/testsuite/gdb.ada/float-bits.exp b/gdb/testsuite/gdb.ada/float-bits.exp
index 921fe36a4bd..dab16a60286 100644
--- a/gdb/testsuite/gdb.ada/float-bits.exp
+++ b/gdb/testsuite/gdb.ada/float-bits.exp
@@ -75,14 +75,21 @@ set gdb_long_double_size [float_size "16llf#0#" ]
 
 # 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 cmd "maint print architecture"
+gdb_test_multiple $cmd  "" {
+    -re "^[string_to_regexp $cmd](?=\r\n)" {
+	exp_continue
+    }
+    -re "^\r\ngdbarch_dump: long_double_format = (\[^\r\n\]*)(?=\r\n)" {
 	set long_double_format $expect_out(1,string)
 	exp_continue
     }
-    -re -wrap "" {
+    -re "^\r\n$gdb_prompt $" {
 	pass $gdb_test_name
     }
+    -re "^\r\n(\[^\r\n\]*)(?=\r\n)" {
+	exp_continue
+    }
 }
 
 # Set default values for 128-bit IEEE quad long doubles.

base-commit: 6ef35c04dffe685ece08212201c4c032baf8aa86
-- 
2.35.3

Re: [PATCH] [gdb/testsuite] Fix gdb.ada/float-bits.exp for powerpc64le

[Luis Machado]

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.

Re: [PATCH] [gdb/testsuite] Fix gdb.ada/float-bits.exp for powerpc64le

[Luis Machado]

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.

Re: [PATCH] [gdb/testsuite] Fix gdb.ada/float-bits.exp for powerpc64le

[Tom de Vries]

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