[PATCH] gdb/fortran Fixed printing of logical true values for Flang

[PATCH] gdb/fortran Fixed printing of logical true values for Flang

[Sharma, Alok Kumar]

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

Hi all,

I request you all to please review the patch. Below are the details.

Problem Description:

gdb is not able to print logical true values for Flang compiler.
    actual result
    --------------
    (gdb) p l
    $1 = 4294967295
    --------------
    expected result
    --------------
    (gdb) p l
    $1 = .TRUE.
    --------------

Root cause:

    This is due to GDB expecting representation of true value being 1.
    The fortran standard doesnt specify how LOGICAL types are represented.
    Different compilers use different non zero values to represent LOGICAL
    TRUE. The gfortran compiler uses 1 to represent LOGICAL TRUE and flang
    compiler uses -1. GDB should accept all the non zero values as TRUE.

Resolution:

    Now function 'generic_val_print_bool' is modified to be able to print
    true logical value for the Flang compiler.

Testing:

- No regression seen

Please let me know your comments.

Regards,
Alok

[-- Attachment #2: 0001-gdb-fortran-Fixed-printing-of-logical-true-values-fo.patch --]
[-- Type: application/octet-stream, Size: 1883 bytes --]

From f8a7a8070df398a143e49ed6f8d2702583689342 Mon Sep 17 00:00:00 2001
From: Alok Kumar Sharma <AlokKumar.Sharma@amd.com>
Date: Mon, 2 Mar 2020 21:49:50 +0530
Subject: [PATCH] gdb/fortran Fixed printing of logical true values for Flang

gdb is not able to print logical true values for Flang compiler.
actual result
--------------
(gdb) p l
$1 = 4294967295
--------------
expected result
--------------
(gdb) p l
$1 = .TRUE.
--------------
This is due to GDB expecting representation of true value being 1.
The fortran standard doesnt specify how LOGICAL types are represented.
Different compilers use different non zero values to represent LOGICAL
TRUE. The gfortran compiler uses 1 to represent LOGICAL TRUE and flang
compiler uses -1. GDB should accept all the non zero values as TRUE.
Now function 'generic_val_print_bool' is modified to be able to print
true logical value for the Flang compiler.

gdb/ChangeLog:

	* valprint.c (generic_val_print_bool): Changed to treat any
	non-zero value as TRUE for fortran LOGICAL type.

Change-Id: I0509c5b50bf3481b9fca2aad46fb17742ec9aae3
---
 gdb/valprint.c | 5 ++++-
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/gdb/valprint.c b/gdb/valprint.c
index 8adbb3df45..1de0ebd3df 100644
--- a/gdb/valprint.c
+++ b/gdb/valprint.c
@@ -793,7 +793,10 @@ generic_val_print_bool (struct type *type,
       val = unpack_long (type, valaddr + embedded_offset * unit_size);
       if (val == 0)
 	fputs_filtered (decorations->false_name, stream);
-      else if (val == 1)
+      /* The fortran standard doesnt specify how LOGICAL types are represented.
+         Different compilers use different non zero values to represent LOGICAL
+         TRUE.  */
+      else if (current_language == &f_language_defn || val == 1)
 	fputs_filtered (decorations->true_name, stream);
       else
 	print_longest (stream, 'd', 0, val);
-- 
2.17.1

[PATCHv2] gdb/fortran: Fix printing of logical true values for Flang

[Andrew Burgess]

Alok,

Thanks for looking into this.  I think that the best solution right
now will be to handle TYPE_CODE_BOOL in f_val_print rather than
modifying generic_val_print_bool.

The other possibility would be, I think, to add a new field to 'struct
language_defn' and use this in generic_val_print_bool instead of
comparing the value of current_lanuage directly, however, this isn't
the common approach, so I'd prefer to handle this case just like other
TYPE_CODE_* are handled for now.

I know that in places within GDB we do compare the value of
current_lanuage to the know language structures, but I'd like to move
us away from doing this.

I've gone ahead and added some tests too.

Let me know what you think of this.  If you're happy then I'll go
ahead and push this.

Thanks
Andrew

---

GDB is not able to print logical true values for Flang compiler.

Actual result:

  (gdb) p l
  $1 = 4294967295

Expected result:

  (gdb) p l
  $1 = .TRUE.

This is due to GDB expecting representation of true value being 1.
The Fortran standard doesnt specify how LOGICAL types are represented.
Different compilers use different non-zero values to represent logical
true. The gfortran compiler uses 1 to represent logical true and the
flang compiler uses -1. GDB should accept all the non-zero values as
true.

This is achieved by handling TYPE_CODE_BOOL in f_val_print and
printing any non-zero value as true.

gdb/ChangeLog:

	* f-valprint.c (f_val_print): Handle TYPE_CODE_BOOL, any non-zero
	value should be printed as true.

gdb/testsuite/ChangeLog:

	* gdb.fortran/logical.exp: Add tests that any non-zero value is
	printed as true.
---
 gdb/ChangeLog                         |  6 ++++++
 gdb/f-valprint.c                      | 25 ++++++++++++++++++++++++-
 gdb/testsuite/ChangeLog               |  5 +++++
 gdb/testsuite/gdb.fortran/logical.exp | 18 ++++++++++++++++++
 4 files changed, 53 insertions(+), 1 deletion(-)

diff --git a/gdb/f-valprint.c b/gdb/f-valprint.c
index a25e6147322..0393ddfa8ab 100644
--- a/gdb/f-valprint.c
+++ b/gdb/f-valprint.c
@@ -357,6 +357,30 @@ f_val_print (struct type *type, int embedded_offset,
       fprintf_filtered (stream, " )");
       break;     
 
+    case TYPE_CODE_BOOL:
+      if (options->format || options->output_format)
+	{
+	  struct value_print_options opts = *options;
+	  opts.format = (options->format ? options->format
+			 : options->output_format);
+	  val_print_scalar_formatted (type, embedded_offset,
+				      original_value, &opts, 0, stream);
+	}
+      else
+	{
+	  int unit_size = gdbarch_addressable_memory_unit_size (gdbarch);
+	  LONGEST val
+	    = unpack_long (type, valaddr + embedded_offset * unit_size);
+	  /* The Fortran standard doesn't specify how logical types are
+	     represented.  Different compilers use different non zero
+	     values to represent logical true.  */
+	  if (val == 0)
+	    fputs_filtered (f_decorations.false_name, stream);
+	  else
+	    fputs_filtered (f_decorations.true_name, stream);
+	}
+      break;
+
     case TYPE_CODE_REF:
     case TYPE_CODE_FUNC:
     case TYPE_CODE_FLAGS:
@@ -366,7 +390,6 @@ f_val_print (struct type *type, int embedded_offset,
     case TYPE_CODE_RANGE:
     case TYPE_CODE_UNDEF:
     case TYPE_CODE_COMPLEX:
-    case TYPE_CODE_BOOL:
     case TYPE_CODE_CHAR:
     default:
       generic_val_print (type, embedded_offset, address,
diff --git a/gdb/testsuite/gdb.fortran/logical.exp b/gdb/testsuite/gdb.fortran/logical.exp
index f0028159e59..96e6f8f9559 100644
--- a/gdb/testsuite/gdb.fortran/logical.exp
+++ b/gdb/testsuite/gdb.fortran/logical.exp
@@ -33,3 +33,21 @@ gdb_test "p l1" " = \\.TRUE\\."
 gdb_test "p l2" " = \\.TRUE\\."
 gdb_test "p l4" " = \\.TRUE\\."
 gdb_test "p l8" " = \\.TRUE\\."
+
+# Different Fortran compilers use different values for logical true.
+# Check how GDB handles this by modifying the underlying value for our
+# logical variables and check they still print as true.
+foreach_with_prefix var { l l1 l2 l4 l8 } {
+    set len [get_integer_valueof "sizeof (${var})" "get sizeof ${var}"]
+    set addr [get_hexadecimal_valueof "&l" "get address of ${var}"]
+
+    for { set i 0 } { $i < $len } { incr i } {
+	with_test_prefix "byte $i" {
+	    gdb_test_no_output "set *((uint8_t *) ${addr}) = 0xff" \
+		"set contents of byte at offset $i"
+	    gdb_test "p l" " = \\.TRUE\\."
+	    incr addr
+	    set addr [format "0x%x" $addr]
+	}
+    }
+}
-- 
2.14.5

RE: [PATCHv2] gdb/fortran: Fix printing of logical true values for Flang

[Sharma, Alok Kumar]

Hi Andrew,

I strongly agree and accept your comment. Please let me know if patch need to be updated by me? In case you have already incorporated the comments, please push it.

Regards,
Alok

-----Original Message-----
From: Andrew Burgess <andrew.burgess@embecosm.com> 
Sent: Monday, March 2, 2020 11:52 PM
To: gdb-patches@sourceware.org
Cc: Sharma, Alok Kumar <AlokKumar.Sharma@amd.com>; Andrew Burgess <andrew.burgess@embecosm.com>
Subject: [PATCHv2] gdb/fortran: Fix printing of logical true values for Flang

[CAUTION: External Email]

Alok,

Thanks for looking into this.  I think that the best solution right now will be to handle TYPE_CODE_BOOL in f_val_print rather than modifying generic_val_print_bool.

The other possibility would be, I think, to add a new field to 'struct language_defn' and use this in generic_val_print_bool instead of comparing the value of current_lanuage directly, however, this isn't the common approach, so I'd prefer to handle this case just like other
TYPE_CODE_* are handled for now.

I know that in places within GDB we do compare the value of current_lanuage to the know language structures, but I'd like to move us away from doing this.

I've gone ahead and added some tests too.

Let me know what you think of this.  If you're happy then I'll go ahead and push this.

Thanks
Andrew

---

GDB is not able to print logical true values for Flang compiler.

Actual result:

  (gdb) p l
  $1 = 4294967295

Expected result:

  (gdb) p l
  $1 = .TRUE.

This is due to GDB expecting representation of true value being 1.
The Fortran standard doesnt specify how LOGICAL types are represented.
Different compilers use different non-zero values to represent logical true. The gfortran compiler uses 1 to represent logical true and the flang compiler uses -1. GDB should accept all the non-zero values as true.

This is achieved by handling TYPE_CODE_BOOL in f_val_print and printing any non-zero value as true.

gdb/ChangeLog:

        * f-valprint.c (f_val_print): Handle TYPE_CODE_BOOL, any non-zero
        value should be printed as true.

gdb/testsuite/ChangeLog:

        * gdb.fortran/logical.exp: Add tests that any non-zero value is
        printed as true.
---
 gdb/ChangeLog                         |  6 ++++++
 gdb/f-valprint.c                      | 25 ++++++++++++++++++++++++-
 gdb/testsuite/ChangeLog               |  5 +++++
 gdb/testsuite/gdb.fortran/logical.exp | 18 ++++++++++++++++++
 4 files changed, 53 insertions(+), 1 deletion(-)

diff --git a/gdb/f-valprint.c b/gdb/f-valprint.c index a25e6147322..0393ddfa8ab 100644
--- a/gdb/f-valprint.c
+++ b/gdb/f-valprint.c
@@ -357,6 +357,30 @@ f_val_print (struct type *type, int embedded_offset,
       fprintf_filtered (stream, " )");
       break;

+    case TYPE_CODE_BOOL:
+      if (options->format || options->output_format)
+       {
+         struct value_print_options opts = *options;
+         opts.format = (options->format ? options->format
+                        : options->output_format);
+         val_print_scalar_formatted (type, embedded_offset,
+                                     original_value, &opts, 0, stream);
+       }
+      else
+       {
+         int unit_size = gdbarch_addressable_memory_unit_size (gdbarch);
+         LONGEST val
+           = unpack_long (type, valaddr + embedded_offset * unit_size);
+         /* The Fortran standard doesn't specify how logical types are
+            represented.  Different compilers use different non zero
+            values to represent logical true.  */
+         if (val == 0)
+           fputs_filtered (f_decorations.false_name, stream);
+         else
+           fputs_filtered (f_decorations.true_name, stream);
+       }
+      break;
+
     case TYPE_CODE_REF:
     case TYPE_CODE_FUNC:
     case TYPE_CODE_FLAGS:
@@ -366,7 +390,6 @@ f_val_print (struct type *type, int embedded_offset,
     case TYPE_CODE_RANGE:
     case TYPE_CODE_UNDEF:
     case TYPE_CODE_COMPLEX:
-    case TYPE_CODE_BOOL:
     case TYPE_CODE_CHAR:
     default:
       generic_val_print (type, embedded_offset, address, diff --git a/gdb/testsuite/gdb.fortran/logical.exp b/gdb/testsuite/gdb.fortran/logical.exp
index f0028159e59..96e6f8f9559 100644
--- a/gdb/testsuite/gdb.fortran/logical.exp
+++ b/gdb/testsuite/gdb.fortran/logical.exp
@@ -33,3 +33,21 @@ gdb_test "p l1" " = \\.TRUE\\."
 gdb_test "p l2" " = \\.TRUE\\."
 gdb_test "p l4" " = \\.TRUE\\."
 gdb_test "p l8" " = \\.TRUE\\."
+
+# Different Fortran compilers use different values for logical true.
+# Check how GDB handles this by modifying the underlying value for our 
+# logical variables and check they still print as true.
+foreach_with_prefix var { l l1 l2 l4 l8 } {
+    set len [get_integer_valueof "sizeof (${var})" "get sizeof ${var}"]
+    set addr [get_hexadecimal_valueof "&l" "get address of ${var}"]
+
+    for { set i 0 } { $i < $len } { incr i } {
+       with_test_prefix "byte $i" {
+           gdb_test_no_output "set *((uint8_t *) ${addr}) = 0xff" \
+               "set contents of byte at offset $i"
+           gdb_test "p l" " = \\.TRUE\\."
+           incr addr
+           set addr [format "0x%x" $addr]
+       }
+    }
+}
--
2.14.5

Re: [PATCHv2] gdb/fortran: Fix printing of logical true values for Flang

[Tom Tromey]

>>>>> "Andrew" == Andrew Burgess <andrew.burgess@embecosm.com> writes:

Andrew> Thanks for looking into this.  I think that the best solution right
Andrew> now will be to handle TYPE_CODE_BOOL in f_val_print rather than
Andrew> modifying generic_val_print_bool.

Agreed.

Andrew> The other possibility would be, I think, to add a new field to 'struct
Andrew> language_defn' and use this in generic_val_print_bool instead of
Andrew> comparing the value of current_lanuage directly, however, this isn't
Andrew> the common approach, so I'd prefer to handle this case just like other
Andrew> TYPE_CODE_* are handled for now.

It would be nice if we could get away from having separate printing code
for each language.  I don't know how practical this is though.

Andrew> I know that in places within GDB we do compare the value of
Andrew> current_lanuage to the know language structures, but I'd like to move
Andrew> us away from doing this.

Also agreed.

Tom

Re: [PATCHv2] gdb/fortran: Fix printing of logical true values for Flang

[Andrew Burgess]

* Tom Tromey <tom@tromey.com> [2020-03-03 09:31:55 -0700]:

> >>>>> "Andrew" == Andrew Burgess <andrew.burgess@embecosm.com> writes:
> 
> Andrew> Thanks for looking into this.  I think that the best solution right
> Andrew> now will be to handle TYPE_CODE_BOOL in f_val_print rather than
> Andrew> modifying generic_val_print_bool.
> 
> Agreed.
> 
> Andrew> The other possibility would be, I think, to add a new field to 'struct
> Andrew> language_defn' and use this in generic_val_print_bool instead of
> Andrew> comparing the value of current_lanuage directly, however, this isn't
> Andrew> the common approach, so I'd prefer to handle this case just like other
> Andrew> TYPE_CODE_* are handled for now.
> 
> It would be nice if we could get away from having separate printing code
> for each language.  I don't know how practical this is though.

I am slowly working on converting the language structure into a true
class, my thinking is that this would make it much easier to add more
per-language functions, and specialise as needed.

In this case we would then remove the special handling for Fortran and
make the common code be something like:

      ....
      const gdb_byte *valaddr = value_contents_for_printing (original_value);

      val = unpack_long (type, valaddr + embedded_offset * unit_size);
      if (current_language->is_logical_false (val))
	fputs_filtered (decorations->false_name, stream);
      else if (current_language->is_logical_true (val))
	fputs_filtered (decorations->true_name, stream);
      else
	print_longest (stream, 'd', 0, val);
      ....

I think there's lots of places in the value printing (and maybe
evaluation) code where we copy blocks of code just to allow for small
specialisations, I'd hope we could start to recombine some of this
stuff...

Thanks,
Andrew



> 
> Andrew> I know that in places within GDB we do compare the value of
> Andrew> current_lanuage to the know language structures, but I'd like to move
> Andrew> us away from doing this.
> 
> Also agreed.
> 
> Tom

Re: [PATCHv2] gdb/fortran: Fix printing of logical true values for Flang

[Andrew Burgess]

* Sharma, Alok Kumar <AlokKumar.Sharma@amd.com> [2020-03-03 04:47:20 +0000]:

> I strongly agree and accept your comment. Please let me know if
> patch need to be updated by me? In case you have already
> incorporated the comments, please push it.

I pushed this change.

Thanks,
Andrew

[gdb/testsuite] Fix missing uint8_t in gdb.fortran/logical.exp

[Tom de Vries]

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

[ was: Re: [PATCHv2] gdb/fortran: Fix printing of logical true values
for Flang ]

On 03-03-2020 19:21, Andrew Burgess wrote:
> * Sharma, Alok Kumar <AlokKumar.Sharma@amd.com> [2020-03-03 04:47:20 +0000]:
> 
>> I strongly agree and accept your comment. Please let me know if
>> patch need to be updated by me? In case you have already
>> incorporated the comments, please push it.
> 
> I pushed this change.

I'm running into trouble with the test-case.  Attached patch fixes that.

OK for trunk?

Thanks,
- Tom

[-- Attachment #2: 0001-gdb-testsuite-Fix-missing-uint8_t-in-gdb.fortran-logical.exp.patch --]
[-- Type: text/x-patch, Size: 1881 bytes --]

[gdb/testsuite] Fix missing uint8_t in gdb.fortran/logical.exp

With test-case gdb.fortran/logical.exp, I run into:
...
(gdb) PASS: gdb.fortran/logical.exp: var=l: get hexadecimal valueof "&l"
set *((uint8_t *) 0x7fffffffd2bc) = 0xff^M
No symbol "uint8_t" in current context.^M
(gdb) FAIL: gdb.fortran/logical.exp: var=l: byte 0: set contents of byte at offset 0
...

Fix this by using the fortran-native type character instead.

Tested on x86_64-linux, with gcc 7.5.0 and clang 5.0.2.

gdb/testsuite/ChangeLog:

2020-03-04  Tom de Vries  <tdevries@suse.de>

	* gdb.fortran/logical.f90: Define variable with character type.
	* gdb.fortran/logical.exp: Use character type instead of uint8_t.

---
 gdb/testsuite/gdb.fortran/logical.exp | 2 +-
 gdb/testsuite/gdb.fortran/logical.f90 | 2 ++
 2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.fortran/logical.exp b/gdb/testsuite/gdb.fortran/logical.exp
index 96e6f8f955..324714fa49 100644
--- a/gdb/testsuite/gdb.fortran/logical.exp
+++ b/gdb/testsuite/gdb.fortran/logical.exp
@@ -43,7 +43,7 @@ foreach_with_prefix var { l l1 l2 l4 l8 } {
 
     for { set i 0 } { $i < $len } { incr i } {
 	with_test_prefix "byte $i" {
-	    gdb_test_no_output "set *((uint8_t *) ${addr}) = 0xff" \
+	    gdb_test_no_output "set *((character *) ${addr}) = 0xff" \
 		"set contents of byte at offset $i"
 	    gdb_test "p l" " = \\.TRUE\\."
 	    incr addr
diff --git a/gdb/testsuite/gdb.fortran/logical.f90 b/gdb/testsuite/gdb.fortran/logical.f90
index aea78e7089..175dfd1fc5 100644
--- a/gdb/testsuite/gdb.fortran/logical.f90
+++ b/gdb/testsuite/gdb.fortran/logical.f90
@@ -21,10 +21,12 @@ program test
   logical (kind=2) :: l2
   logical (kind=4) :: l4
   logical (kind=8) :: l8
+  character :: c
   l = .TRUE.
   l1 = .TRUE.
   l2 = .TRUE.
   l4 = .TRUE.
   l8 = .TRUE.
   l = .FALSE.					! stop-here
+  c = 'a'
 end

Re: [gdb/testsuite] Fix missing uint8_t in gdb.fortran/logical.exp

[Andrew Burgess]

* Tom de Vries <tdevries@suse.de> [2020-03-04 09:48:22 +0100]:

> [ was: Re: [PATCHv2] gdb/fortran: Fix printing of logical true values
> for Flang ]
> 
> On 03-03-2020 19:21, Andrew Burgess wrote:
> > * Sharma, Alok Kumar <AlokKumar.Sharma@amd.com> [2020-03-03 04:47:20 +0000]:
> > 
> >> I strongly agree and accept your comment. Please let me know if
> >> patch need to be updated by me? In case you have already
> >> incorporated the comments, please push it.
> > 
> > I pushed this change.
> 
> I'm running into trouble with the test-case.  Attached patch fixes that.
> 
> OK for trunk?

LGTM.

Thanks for this fix.

> 
> Thanks,
> - Tom

> [gdb/testsuite] Fix missing uint8_t in gdb.fortran/logical.exp
> 
> With test-case gdb.fortran/logical.exp, I run into:
> ...
> (gdb) PASS: gdb.fortran/logical.exp: var=l: get hexadecimal valueof "&l"
> set *((uint8_t *) 0x7fffffffd2bc) = 0xff^M
> No symbol "uint8_t" in current context.^M
> (gdb) FAIL: gdb.fortran/logical.exp: var=l: byte 0: set contents of byte at offset 0
> ...
> 
> Fix this by using the fortran-native type character instead.
> 
> Tested on x86_64-linux, with gcc 7.5.0 and clang 5.0.2.

I dug into this because, as we discussed on IRC you are seeing
failures with 7.5, while I am seeing passes with 7.4.  For me I was
getting the symbol from libgfortan.  I wonder if it's possible that
you're linking against an older version of libgfortran, even with a
newer gcc?

Either way, I think this fix should be merged, so feel free to go
ahead.

Thanks,
Andrew




> 
> gdb/testsuite/ChangeLog:
> 
> 2020-03-04  Tom de Vries  <tdevries@suse.de>
> 
> 	* gdb.fortran/logical.f90: Define variable with character type.
> 	* gdb.fortran/logical.exp: Use character type instead of uint8_t.
> 
> ---
>  gdb/testsuite/gdb.fortran/logical.exp | 2 +-
>  gdb/testsuite/gdb.fortran/logical.f90 | 2 ++
>  2 files changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/gdb/testsuite/gdb.fortran/logical.exp b/gdb/testsuite/gdb.fortran/logical.exp
> index 96e6f8f955..324714fa49 100644
> --- a/gdb/testsuite/gdb.fortran/logical.exp
> +++ b/gdb/testsuite/gdb.fortran/logical.exp
> @@ -43,7 +43,7 @@ foreach_with_prefix var { l l1 l2 l4 l8 } {
>  
>      for { set i 0 } { $i < $len } { incr i } {
>  	with_test_prefix "byte $i" {
> -	    gdb_test_no_output "set *((uint8_t *) ${addr}) = 0xff" \
> +	    gdb_test_no_output "set *((character *) ${addr}) = 0xff" \
>  		"set contents of byte at offset $i"
>  	    gdb_test "p l" " = \\.TRUE\\."
>  	    incr addr
> diff --git a/gdb/testsuite/gdb.fortran/logical.f90 b/gdb/testsuite/gdb.fortran/logical.f90
> index aea78e7089..175dfd1fc5 100644
> --- a/gdb/testsuite/gdb.fortran/logical.f90
> +++ b/gdb/testsuite/gdb.fortran/logical.f90
> @@ -21,10 +21,12 @@ program test
>    logical (kind=2) :: l2
>    logical (kind=4) :: l4
>    logical (kind=8) :: l8
> +  character :: c
>    l = .TRUE.
>    l1 = .TRUE.
>    l2 = .TRUE.
>    l4 = .TRUE.
>    l8 = .TRUE.
>    l = .FALSE.					! stop-here
> +  c = 'a'
>  end

Re: [gdb/testsuite] Fix missing uint8_t in gdb.fortran/logical.exp

[Tom de Vries]

On 11-03-2020 11:24, Andrew Burgess wrote:
>> [gdb/testsuite] Fix missing uint8_t in gdb.fortran/logical.exp
>>
>> With test-case gdb.fortran/logical.exp, I run into:
>> ...
>> (gdb) PASS: gdb.fortran/logical.exp: var=l: get hexadecimal valueof "&l"
>> set *((uint8_t *) 0x7fffffffd2bc) = 0xff^M
>> No symbol "uint8_t" in current context.^M
>> (gdb) FAIL: gdb.fortran/logical.exp: var=l: byte 0: set contents of byte at offset 0
>> ...
>>
>> Fix this by using the fortran-native type character instead.
>>
>> Tested on x86_64-linux, with gcc 7.5.0 and clang 5.0.2.
> 
> I dug into this because, as we discussed on IRC you are seeing
> failures with 7.5, while I am seeing passes with 7.4.  For me I was
> getting the symbol from libgfortan.  I wonder if it's possible that
> you're linking against an older version of libgfortran, even with a
> newer gcc?
> 

Hi Andrew,

Just to confirm:
- I installed all debuginfo packages that my openSUSE system gdb
  suggested for the executable, and
- I rebuild gdb with configure flag
  --with-separate-debug-dir=/usr/lib/debug

After these two modifications, the test passes for me without the patch.

Thanks,
- Tom