User account creation filtered due to spam.
(I am not exactly sure whether gfortran or gdb are to blame for this issue, but I tend towards the former.) The following causes gdb 7.4 to report missing symbols in current context when compiled with recent gfortran versions: $ cat <<EOF > debug.f90 program debug use module implicit none type(myint), dimension(1) :: bar call foo(bar) end program debug EOF $ cat <<EOF > module.f90 module module implicit none type myint integer :: i = -1 end type myint contains subroutine foo(bar) type(myint), dimension(:) :: bar call subfoo() contains subroutine subfoo() bar(1)%i = 1 print *, bar(1)%i end subroutine subfoo end subroutine foo end module module EOF $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gcc/4.9.0/libexec/gcc/x86_64-unknown-linux-gnu/4.9.0/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../gcc-4.9.0/configure --prefix=/usr/local/gcc/4.9.0 --enable-languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 4.9.0 (GCC) $ gfortran -O0 -g -fno-inline -Wall -Wextra -c module.f90 $ gfortran -O0 -g -fno-inline -Wall -Wextra -fno-lto debug.f90 module.o $ gdb --version GNU gdb (Ubuntu/Linaro 7.4-2012.04-0ubuntu2.1) 7.4-2012.04 Copyright (C) 2012 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html> This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Type "show copying" and "show warranty" for details. This GDB was configured as "x86_64-linux-gnu". For bug reporting instructions, please see: <http://bugs.launchpad.net/gdb-linaro/>. $ gdb a.out (gdb) break module.f90:10 Breakpoint 1 at 0x4007a0: file module.f90, line 10. (gdb) break module.f90:14 Breakpoint 2 at 0x400703: file module.f90, line 14. (gdb) run Starting program: /tmp/a.out Breakpoint 1, 0x00000000004007a0 in __module_MOD_foo () (gdb) print bar(1)%i No symbol "bar" in current context. (gdb) cont Continuing. Breakpoint 2, 0x0000000000400703 in subfoo.2335 () (gdb) print bar(1)%i No symbol "bar" in current context. # Dito with GCC 4.8.2. # With GCC 4.6.3 and 4.7.3 the respective results of the two print commands in gdb are: $1 = -1 value has been optimized out # Whereas with GCC 4.4.7 and GCC 4.5.4 the very same version of gdb is able to show the (expected) value of component i of the first entry of array "bar" at both breakpoints: $1 = -1 $2 = -1 $ gfortran -v Using built-in specs. COLLECT_GCC=gfortran COLLECT_LTO_WRAPPER=/usr/local/gcc/4.5.4/libexec/gcc/x86_64-unknown-linux-gnu/4.5.4/lto-wrapper Target: x86_64-unknown-linux-gnu Configured with: ../configure --prefix=/usr/local/gcc/4.5.4 --enable-languages=c,c++,fortran --disable-multilib Thread model: posix gcc version 4.5.4 (GCC) ### With Intel Fortran 14.0.1.106 (aka XE 2013 SP1 Update 1) and its accompanying debugger one can query the value always: $ ifort -O0 -g -Warn all -c module.f90 $ ifort -O0 -g -Warn all -c debug.f90 $ ifort -O0 -g -Warn all debug.o module.o $ idbc a.out Intel(R) Debugger for applications running on Intel(R) 64, Version 13.0, Build [80.483.23] ------------------ object file name: a.out Reading symbols from /tmp/a.out...done. (idb) break module.f90:10 Breakpoint 1 at 0x402ca5: file /tmp/module.f90, line 10. (idb) break module.f90:14 Breakpoint 2 at 0x402ce8: file /tmp/module.f90, line 14. (idb) run Starting program: /tmp/a.out [New Thread 23410 (LWP 23410)] Breakpoint 1, MODULE::foo (bar=(...)) at /tmp/module.f90:10 10 call subfoo() (idb) print bar(1)%i $1 = -1 (idb) cont Continuing. Breakpoint 2, subfoo () at /tmp/module.f90:14 14 bar(1)%i = 1 (idb) print bar(1)%i $2 = -1 (idb) next 15 print *, bar(1)%i (idb) print bar(1)%i $3 = 1
I get (gdb 7.7): Breakpoint 1, module::foo (bar=...) at module.f90:10 10 call subfoo() (gdb) p bar $1 = (( -1 )) (gdb) p bar(1)%i $2 = -1 (gdb) s module::subfoo () at module.f90:14 14 bar(1)%i = 1 (gdb) p bar(1)%i value being subranged must be in memory (gdb) p bar $3 = <optimized out> seems that nested function lowering and debugging don't play well together. Confirmed that it works well with 4.5.x.
(In reply to Sven Buijssen from comment #0) > (I am not exactly sure whether gfortran or gdb are to blame for this issue, > but I tend towards the former.) > $ gfortran -O0 -g -fno-inline -Wall -Wextra -fno-lto debug.f90 module.o > $ gdb --version > $ ifort -O0 -g -Warn all debug.o module.o > $ idbc a.out As you also have "idb" at hand: You could cross check whether the GCC/gfortran binary works with idbc - and the ifort binary with gdb. They both use the same debugging format (which can differ slightly between versions). > subroutine foo(bar) > type(myint), dimension(:) :: bar This line implies that gfortran uses array descriptors; those are not yet supported in GDB - except that some vendor's versions (e.g. Red Hat/Fedora and (open)SUSE have some basic support. There is an on-going effort to add arrays-descriptor support to GDB; the first step, the support of C99's varying-length arrays has been added a few weeks ago to the GDB trunk. The Fortran support is supposed to come next, but it still will take a couple of weeks. See also: https://github.com/intel-gdb/vla/branches - but the Fortran branch there is a bit outdated. However, ... (In reply to Richard Biener from comment #1) > I get (gdb 7.7): ... > seems that nested function lowering and debugging don't play well together. > Confirmed that it works well with 4.5.x. The combination that it works with 4.5 and that also a SUSE-build of gdb shows the problem, makes it more likely that the problem lies elsewhere. (It might be still a combination of changed dwarf generation in GCC and incomplete GDB support.)
(In reply to Tobias Burnus from comment #2) > As you also have "idb" at hand I now did it myself with gcc 4.10 and idbc 13.0. (I don't have ifort.) Result: In line 10, I get: (idb) p bar $3 = {i = -1} but in line 14, I get: `module::foo::subfoo () at /dev/shm/h4j.f90:14 14 bar(1)%i = 1 (idb) p bar Info: symbol bar is defined but not allocated (optimized away) Thus, as Richard wrote: > seems that nested function lowering and debugging don't play well together.
I tried gdb 7.7 with Intel Fortran 10.1.023, 11.1.080, 12.1.7.367, 13.0.1.117, 13.1.3.192 and 14.0.2.144, respectively and get wrong results at breakpoint 1 (value of bar(1)%i = 0) and either "no symbol" or "cannot access memory" at breakpoint 2: ifort 10.1.023: Breakpoint 1, MODULE::foo (bar=..., bar=...) at module.f90:10 10 call subfoo() (gdb) p bar $1 = (( 0 )) (gdb) c Continuing. Breakpoint 2, 0x0000000000402af8 in modulefoo_mp_subfoo_ () (gdb) p bar No symbol "bar" in current context. # ifort 11.1.080 & 12.1.7.367 & 13.0.1.117 & 13.1.3.192: Breakpoint 1, MODULE::foo (bar=...) at module.f90:10 10 call subfoo() (gdb) p bar $1 = (( 0 )) (gdb) c Continuing. Breakpoint 2, MODULE::subfoo () at module.f90:14 14 bar(1)%i = 1 (gdb) p bar $2 = (( 0 )) (gdb) p bar(1)%i Cannot access memory at address 0x4 # ifort 14.0.2.144: Breakpoint 1, MODULE::foo (bar=...) at module.f90:10 10 call subfoo() (gdb) p bar $1 = (( 0 )) (gdb) c Continuing. Breakpoint 2, modulefoo_mp_subfoo_ () at module.f90:14 14 bar(1)%i = 1 (gdb) p bar No symbol "bar" in current context. (gdb) p bar(1)%i No symbol "bar" in current context.
git bisect along with a suitable script identified this gcc commit as culprit: commit 599471650d6f0fb42b1c1c7e6b24ca21e65132fa Author: ebotcazou <ebotcazou@138bc75d-0d04-0410-961f-82ee72b054a4> Date: Sat Nov 27 15:53:23 2010 +0000 config/ * bootstrap-lto.mk (BOOT_ADAFLAGS): Delete. gcc/ * tree-nested.c (remap_vla_decls): Fully expand value expressions of VLA variables. gcc/ada/ * gnatvsn.adb (Version_String): Change type to C-like array of chars. (Gnat_Version_String): Adjust to above change. Since it got merged, gdb can not query bar(1)%i in subfoo() any more.
For crossref, that was the patch r167201: "[patch] Enable Ada bootstrap with LTO" http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02644.html
> seems that nested function lowering and debugging don't play well together. Note that sometimes nested functions appear to work in gdb -- but actually they do not, and if you get the right answer it is largely just luck. gdb ignores DW_AT_static_link. My attempt to make gdb understand this failed due to gcc bug #53927. In this particular bug I am going to guess that the problem is the use of non-constant array bounds in the DWARF, which gdb still doesn't understand. There's an ongoing project to fix this.
The 4.7 branch is being closed, moving target milestone to 4.8.4.
GCC 4.8.4 has been released.
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.
GCC 4.9.3 has been released.
GCC 4.9 branch is being closed