aboutsummaryrefslogtreecommitdiff
path: root/gdb/f-lang.c
diff options
context:
space:
mode:
authorNils-Christian Kempke <nils-christian.kempke@intel.com>2022-04-11 14:06:56 +0200
committerNils-Christian Kempke <nils-christian.kempke@intel.com>2022-04-11 14:06:56 +0200
commit87abd9825d8e512dc89a4af8637ca52da42ebc68 (patch)
treea7a34daf0a2eb9bd946782e04cc812b71a8bd421 /gdb/f-lang.c
parentadc29023a741fbeb23dc3e07a0328cca4e9061f1 (diff)
downloadgdb-87abd9825d8e512dc89a4af8637ca52da42ebc68.zip
gdb-87abd9825d8e512dc89a4af8637ca52da42ebc68.tar.gz
gdb-87abd9825d8e512dc89a4af8637ca52da42ebc68.tar.bz2
gdb/fortran: Change GDB print for fortran default types
Currently, when asking GDB to print the type of a Fortran default type such as INTEGER or REAL, GDB will return the default name of that type, e.g. "integer"/"real": (gdb) ptype integer type = integer (gdb) ptype real type = real For LOGICAL and COMPLEX it would return the actual underlying types (gdb) ptype logical type = logical*4 (gdb) ptype complex type = complex*4 Similarly, GDB would print the default integer type for the underlying default type: (gdb) ptype integer*4 type = integer (gdb) ptype real*4 type = real (gdb) ptype logical type = logical*4 (gdb) ptype complex*4 type = complex*4 This is inconsistent and a bit confusing. Both options somehow indicate what the internal underlying type for the default type is - but I think the logical/complex version is a bit clearer. Consider again: (gdb) ptype integer type = integer This indicates to a user that the type of "integer" is Fortran's default integer type. Without examining "ptype integer*4" I would expect, that any variable declared integer in the actual code would also fit into a GDB integer. But, since we cannot adapt out internal types to the compiler flags used at compile time of a debugged binary, this might be wrong. Consider debugging Fortran code compiled with GNU and e.g. the "-fdefault-integer-8" flag. In this case the gfortran default integer would be integer*8 while GDB internally still would use a builtin_integer, so an integer of the size of an integer*4 type. On the other hand having GDB print (gdb) ptype integer type = integer*4 makes this clearer. I would still be tempted to fit a variable declared integer in the code into a GDB integer - but at least ptype would directly tell me what is going on. Note, that when debugging a binary compiled with "-fdefault-integer-8" a user will always see the actual underlying type of any variable declared "integer" in the Fortran code. So having the code program test integer :: a = 5 print *, a ! breakpt end program test will, when breaking at breakpt print (gdb) ptype var type = integer(kind=4) or (gdb) ptype var type = integer(kind=8) depending on the compiler flag. This patch changes the outputs for the REAL and INTEGER default types to actually print the internally used type over the default type name. The new behavior for the above examples is: (gdb) ptype integer type = integer*4 (gdb) ptype integer*4 type = integer*4 Existing testcases have been adapted to reflect the new behavior.
Diffstat (limited to 'gdb/f-lang.c')
-rw-r--r--gdb/f-lang.c4
1 files changed, 2 insertions, 2 deletions
diff --git a/gdb/f-lang.c b/gdb/f-lang.c
index 82252bf..94669c6 100644
--- a/gdb/f-lang.c
+++ b/gdb/f-lang.c
@@ -1636,7 +1636,7 @@ build_fortran_types (struct gdbarch *gdbarch)
= arch_integer_type (gdbarch, gdbarch_short_bit (gdbarch), 0, "integer*2");
builtin_f_type->builtin_integer
- = arch_integer_type (gdbarch, gdbarch_int_bit (gdbarch), 0, "integer");
+ = arch_integer_type (gdbarch, gdbarch_int_bit (gdbarch), 0, "integer*4");
builtin_f_type->builtin_integer_s8
= arch_integer_type (gdbarch, gdbarch_long_long_bit (gdbarch), 0,
@@ -1644,7 +1644,7 @@ build_fortran_types (struct gdbarch *gdbarch)
builtin_f_type->builtin_real
= arch_float_type (gdbarch, gdbarch_float_bit (gdbarch),
- "real", gdbarch_float_format (gdbarch));
+ "real*4", gdbarch_float_format (gdbarch));
builtin_f_type->builtin_real_s8
= arch_float_type (gdbarch, gdbarch_double_bit (gdbarch),