I have encountered a problem while trying to debug Fortran code using gdb 8.1 and after installing gdb 9.2, it still persists. The bug is closely related to #23051. The following MWE helps demonstrate the issue: ```Fortran module test_module type test_type integer a real, allocatable :: b(:, :) contains procedure :: test_proc end type contains subroutine test_proc(this) class(test_type), intent(inout) :: this allocate(this%b(3, 2)) this%b = 0 end subroutine end module program test use test_module implicit none type(test_type) :: t call t%test_proc() end program test ``` When trying to access the allocated component of the dummy argument ```this``` in gdb, the following error occurs: Breakpoint 1, test_module::test_proc (this=...) at test.f90:13 13 this%b = 0 (gdb) print this $1 = ( _data = 0x8202060 <t>, _vptr = 0x8201d40 <__test_module_MOD___vtab_test_module_Test_type> ) (gdb) print this%_data%a $2 = 0 (gdb) print this%_data%b ../../gdb/value.c:2988: internal-error: value* value_primitive_field(value*, LONGEST, int, type*): Assertion `PROP_CONST == TYPE_DATA_LOCATION_KIND (type)' failed. A problem internal to GDB has been detected, further debugging may prove unreliable. Quit this debugging session? (y or n) Accessing simple scalar components like ```a``` is not an issue. I could work around this issue by hand (which is cumbersome), but I need gdb to be integrated with GUI tools.
Patches posted for this bug here: https://sourceware.org/pipermail/gdb-patches/2020-July/170333.html
The master branch has been updated by Andrew Burgess <aburgess@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e79eb02f2f09baecffb144bac6804f975065466f commit e79eb02f2f09baecffb144bac6804f975065466f Author: Andrew Burgess <andrew.burgess@embecosm.com> Date: Thu Jul 9 16:26:23 2020 +0100 gdb/fortran: resolve dynamic types when readjusting after an indirection After dereferencing a pointer (in value_ind) or following a reference (in coerce_ref) we call readjust_indirect_value_type to "fixup" the type of the resulting value object. This fixup handles cases relating to the type of the resulting object being different (a sub-class) of the original pointers target type. If we encounter a pointer to a dynamic type then after dereferencing a pointer (in value_ind) the type of the object created will have had its dynamic type resolved. However, in readjust_indirect_value_type, we use the target type of the original pointer to "fixup" the type of the resulting value. In this case, the target type will be a dynamic type, so the resulting value object, once again has a dynamic type. This then triggers an assertion later within GDB. The solution I propose here is that we call resolve_dynamic_type on the pointer's target type (within readjust_indirect_value_type) so that the resulting value is not converted back to a dynamic type. The test case is based on the original test in the bug report. gdb/ChangeLog: PR fortran/23051 PR fortran/26139 * valops.c (value_ind): Pass address to readjust_indirect_value_type. * value.c (readjust_indirect_value_type): Make parameter non-const, and add extra address parameter. Resolve original type before using it. * value.h (readjust_indirect_value_type): Update function signature and comment. gdb/testsuite/ChangeLog: PR fortran/23051 PR fortran/26139 * gdb.fortran/class-allocatable-array.exp: New file. * gdb.fortran/class-allocatable-array.f90: New file. * gdb.fortran/pointer-to-pointer.exp: New file. * gdb.fortran/pointer-to-pointer.f90: New file.
This issue should now be resolved.
(In reply to Andrew Burgess from comment #3) > This issue should now be resolved. Can confirm it works with the latest build. Thank you so much for the quick fix. This really helps me with my work.