aboutsummaryrefslogtreecommitdiff
path: root/opcodes/disassemble.c
diff options
context:
space:
mode:
authorrupothar <rupesh.potharla@amd.com>2022-03-17 18:56:23 +0000
committerAndrew Burgess <aburgess@redhat.com>2022-04-03 17:18:20 +0100
commitdf7a7bdd9766adebc6b117c31bc617d81c1efd43 (patch)
tree36cf2204ceffa9b267a615088ef7bf5ae51c634b /opcodes/disassemble.c
parent1fb43cf75982f17c27ee0c72328de41750213689 (diff)
downloadgdb-df7a7bdd9766adebc6b117c31bc617d81c1efd43.zip
gdb-df7a7bdd9766adebc6b117c31bc617d81c1efd43.tar.gz
gdb-df7a7bdd9766adebc6b117c31bc617d81c1efd43.tar.bz2
gdb: add support for Fortran's ASSUMED RANK arrays
This patch adds a new dynamic property DYN_PROP_RANK, this property is read from the DW_AT_rank attribute and stored within the type just like other dynamic properties. As arrays with dynamic ranks make use of a single DW_TAG_generic_subrange to represent all ranks of the array, support for this tag has been added to dwarf2/read.c. The final piece of this puzzle is to add support in gdbtypes.c so that we can resolve an array type with dynamic rank. To do this the existing resolve_dynamic_array_or_string function is split into two, there's a new resolve_dynamic_array_or_string_1 core that is responsible for resolving each rank of the array, while the now outer resolve_dynamic_array_or_string is responsible for figuring out the array rank (which might require resolving a dynamic property) and then calling the inner core. The resolve_dynamic_range function now takes a rank, which is passed on to the dwarf expression evaluator. This rank will only be used in the case where the array itself has dynamic rank, but we now pass the rank in all cases, this should be harmless if the rank is not needed. The only small nit is that resolve_dynamic_type_internal actually handles resolving dynamic ranges itself, which now obviously requires us to pass a rank value. But what rank value to use? In the end I just passed '1' through here as a sane default, my thinking is that if we are in resolve_dynamic_type_internal to resolve a range, then the range isn't part of an array with dynamic rank, and so the range should actually be using the rank value at all. An alternative approach would be to make the rank value a gdb::optional, however, this ends up adding a bunch of complexity to the code (e.g. having to conditionally build the array to pass to dwarf2_evaluate_property, and handling the 'rank - 1' in resolve_dynamic_array_or_string_1) so I haven't done that, but could, if people think that would be a better approach. Finally, support for assumed rank arrays was only fixed very recently in gcc, so you'll need the latest gcc in order to run the tests for this. Here's an example test program: PROGRAM arank REAL :: a1(10) CALL sub1(a1) CONTAINS SUBROUTINE sub1(a) REAL :: a(..) PRINT *, RANK(a) END SUBROUTINE sub1 END PROGRAM arank Compiler Version: gcc (GCC) 12.0.0 20211122 (experimental) Compilation command: gfortran assumedrank.f90 -gdwarf-5 -o assumedrank Without Patch: gdb -q assumedrank Reading symbols from assumedrank... (gdb) break sub1 Breakpoint 1 at 0x4006ff: file assumedrank.f90, line 10. (gdb) run Starting program: /home/rupesh/STAGING-BUILD-2787/bin/assumedrank Breakpoint 1, arank::sub1 (a=<unknown type in /home/rupesh/STAGING-BUILD-2787 /bin/assumedrank, CU 0x0, DIE 0xd5>) at assumedrank.f90:10 10 PRINT *, RANK(a) (gdb) print RANK(a) 'a' has unknown type; cast it to its declared type With patch: gdb -q assumedrank Reading symbols from assumedrank... (gdb) break sub1 Breakpoint 1 at 0x4006ff: file assumedrank.f90, line 10. (gdb) run Starting program: /home/rupesh/STAGING-BUILD-2787/bin/assumedrank Breakpoint 1, arank::sub1 (a=...) at assumedrank.f90:10 10 PRINT *, RANK(a) (gdb) print RANK(a) $1 = 1 (gdb) ptype a type = real(kind=4) (10) (gdb) Co-Authored-By: Andrew Burgess <aburgess@redhat.com>
Diffstat (limited to 'opcodes/disassemble.c')
0 files changed, 0 insertions, 0 deletions