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

  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
  

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