[Bug debug/61014] [4.7/4.8/4.9/4.10 Regression] gdb can't find symbol of derived data type array in nested subroutine
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61014 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|4.7.4 |4.8.4 --- Comment #8 from Richard Biener rguenth at gcc dot gnu.org --- The 4.7 branch is being closed, moving target milestone to 4.8.4.
[Bug debug/61014] [4.7/4.8/4.9/4.10 Regression] gdb can't find symbol of derived data type array in nested subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61014 Tom Tromey tromey at gcc dot gnu.org changed: What|Removed |Added CC||tromey at gcc dot gnu.org --- Comment #7 from Tom Tromey tromey at gcc dot gnu.org --- 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.
[Bug debug/61014] [4.7/4.8/4.9/4.10 Regression] gdb can't find symbol of derived data type array in nested subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61014 --- Comment #5 from Sven Buijssen sven.buijssen at math dot uni-dortmund.de --- 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 + 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.
[Bug debug/61014] [4.7/4.8/4.9/4.10 Regression] gdb can't find symbol of derived data type array in nested subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61014 --- Comment #6 from Tobias Burnus burnus at gcc dot gnu.org --- For crossref, that was the patch r167201: [patch] Enable Ada bootstrap with LTO http://gcc.gnu.org/ml/gcc-patches/2010-11/msg02644.html
[Bug debug/61014] [4.7/4.8/4.9/4.10 Regression] gdb can't find symbol of derived data type array in nested subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61014 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2014-04-30 Component|fortran |debug Known to work||4.5.4 Summary|[4.6/4.7/4.8/4.9|[4.7/4.8/4.9/4.10 |Regression] gdb can't find |Regression] gdb can't find |symbol of derived data type |symbol of derived data type |array in nested subroutine |array in nested subroutine Ever confirmed|0 |1 Known to fail||4.8.2 --- Comment #1 from Richard Biener rguenth at gcc dot gnu.org --- 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 14bar(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.
[Bug debug/61014] [4.7/4.8/4.9/4.10 Regression] gdb can't find symbol of derived data type array in nested subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61014 Richard Biener rguenth at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |4.7.4
[Bug debug/61014] [4.7/4.8/4.9/4.10 Regression] gdb can't find symbol of derived data type array in nested subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61014 Tobias Burnus burnus at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #2 from Tobias Burnus burnus at gcc dot gnu.org --- (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.)
[Bug debug/61014] [4.7/4.8/4.9/4.10 Regression] gdb can't find symbol of derived data type array in nested subroutine
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61014
--- Comment #3 from Tobias Burnus burnus at gcc dot gnu.org ---
(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
14bar(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.
