Bug 24526 - renamed variables from modules not visible in gdb
renamed variables from modules not visible in gdb
Status: RESOLVED FIXED
Product: gcc
Classification: Unclassified
Component: fortran
4.1.0
: P2 normal
: ---
Assigned To: Not yet assigned to anyone
: wrong-debug
Depends on:
Blocks: 24546
  Show dependency treegraph
 
Reported: 2005-10-25 19:51 UTC by Thomas Koenig
Modified: 2011-06-27 16:54 UTC (History)
3 users (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2011-06-21 16:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Koenig 2005-10-25 19:51:24 UTC
$ cat module.f90
module foo
  real :: a
end module foo

program main
  use foo, only : a
  a = 42.
  print *,a
end program main
$ gfortran -g module.f90
$ gdb ./a.out
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-linux"...Using host libthread_db library "/lib/tls/libthread_db.so.1".

(gdb) b module.f90:7
Breakpoint 1 at 0x80485e4: file module.f90, line 7.
(gdb) r
Starting program: /home/ig25/Krempel/Gdb/a.out

Breakpoint 1, MAIN__ () at module.f90:7
7         a = 42.
Current language:  auto; currently fortran
(gdb) p a
No symbol "a" in current context.
(gdb)

$ gfortran -v
Using built-in specs.
Target: i686-pc-linux-gnu
Configured with: ../gcc-4.1/configure --prefix=/home/ig25 --enable-languages=c,fortran : (reconfigured) ../gcc-4.1/configure --prefix=/home/ig25 --enable-languages=c,fortran --no-create --no-recursion
Thread model: posix
gcc version 4.1.0 20051011 (experimental)
$ gdb --version
GNU gdb 6.3-debian
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-linux".
Comment 1 Wu Zhou 2005-10-26 03:25:27 UTC
Variable a in modular foo is represented as __foo__a in the DWARF output.  So you can use "print __foo__a" to get the value of modular variable a.

[woodzltc@plinuxt2 ~]$ gdb -q ./modular
Using host libthread_db library "/lib64/tls/libthread_db.so.1".
(gdb) b modular.f90:7
Breakpoint 1 at 0x10001700: file modular.f90, line 7.
(gdb) r
Starting program: /home/woodzltc/modular

Breakpoint 1, MAIN__ () at modular.f90:7
7         a = 42.
Current language:  auto; currently fortran
(gdb) p __foo__a
$2 = 0
(gdb) n
8         print *,a
(gdb) p __foo__a
$3 = 42
(gdb)

To let gdb recognize 'a' directly, some trick in gdb might be needed.
Comment 2 Andrew Pinski 2005-10-27 23:15:15 UTC
(In reply to comment #1)
> To let gdb recognize 'a' directly, some trick in gdb might be needed.

I don't know if some trickery is needed, just we might need to emit something like what C++ does with it using statements.
Comment 3 Steven Bosscher 2006-10-14 14:21:06 UTC
There is support for Fortran module variables in DWARF3, see http://dwarf.freestandards.org/Dwarf3.pdf.

Unfortunately GDB doesn't seem to support this.
Comment 4 Tobias Burnus 2008-08-21 21:31:41 UTC
I think the gfortran part is fixed by PR 29635. The rest has to be solved in gdb. Other debugers seem to have also some problems, e.g. Intel's idb, cf.
http://gcc.gnu.org/ml/fortran/2008-08/msg00128.html
Comment 5 Tobias Burnus 2009-05-29 07:43:19 UTC
Is this a duplicate of PR 40040?
Comment 6 Thomas Koenig 2011-06-23 15:33:31 UTC
Things work now without variable renaming, but with it,
they sometimes don't work.  Adjusting subject.

ig25@linux-fd1f:~/Krempel/GDB> cat rename.f90
module foo                                   
  implicit none                              
  integer :: a_foo = 3                       
  integer :: b_foo = 4                       
end module foo                               

module bar
  use foo, only : b_bar => b_foo
  implicit none
end module bar

module baz
  implicit none
  integer :: c_baz = 5
end module baz

program main
  use foo, only : a_main => a_foo
  use bar, only : b_main => b_bar
  use baz,  c_main => c_baz
  implicit none
  print *, a_main
  print *, b_main
  print *, c_main
end program main
ig25@linux-fd1f:~/Krempel/GDB> gdb ./a.out
GNU gdb (GDB) SUSE (6.8.91.20090930-2.4)
Copyright (C) 2009 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-suse-linux".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from /home/ig25/Krempel/GDB/a.out...done.
(gdb) b MAIN__
Breakpoint 1 at 0x40075f: file rename.f90, line 22.
(gdb) r
Starting program: /home/ig25/Krempel/GDB/a.out
warning: the debug information found in "/usr/lib/debug//lib64/ld-2.10.1.so.debug" does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).

warning: the debug information found in "/usr/lib/debug/lib64/ld-2.10.1.so.debug" does not match "/lib64/ld-linux-x86-64.so.2" (CRC mismatch).

Missing separate debuginfo for /lib64/ld-linux-x86-64.so.2
Try: zypper install -C "debuginfo(build-id)=a121943782877c885215a25513d6bf0bfb6b6723"
warning: the debug information found in "/usr/lib/debug//lib64/libc-2.10.1.so.debug" does not match "/lib64/libc.so.6" (CRC mismatch).

warning: the debug information found in "/usr/lib/debug/lib64/libc-2.10.1.so.debug" does not match "/lib64/libc.so.6" (CRC mismatch).

Missing separate debuginfo for /lib64/libc.so.6
Try: zypper install -C "debuginfo(build-id)=a4762e3dc63d9d17b92a985d53410c4931774ebc"

Breakpoint 1, MAIN__ () at rename.f90:22
22        print *, a_main
Current language:  auto
The current source language is "auto; currently fortran".
(gdb) p a_main
$1 = 3
(gdb) p b_main
No symbol "b_main" in current context.
(gdb) p c_main
No symbol "c_main" in current context.
(gdb)
Comment 7 Tobias Burnus 2011-06-23 16:12:00 UTC
My impression is that this is a bug in GDB and not in GCC (cf. readelf output below). For the following program, the result is: myvar is not found and gdb prints the wrong variable of the two "var33": Namely, the renamed one from "mod" and not the one of "mod2". Using "mod::var33" and "mod2::var33" works as expected. 

14        print *, myvar
(gdb)
          33
15        print *, var33
(gdb)
         -42
16      end program test
(gdb) p var33
$1 = 33
(gdb) p myvar
No symbol "myvar" in current context. 



Test program:

module mod
  integer :: var11 = 11, var22 = 22, var33 = 33
end module mod

module mod2
  integer :: var33 = -42
end module mod2

program test
  use mod, myvar => var33
  use mod2 ! imports var33 == -42
  implicit none
  print *, var11  ! prints: 11
  print *, myvar  ! prints: 33
  print *, var33  ! prints: -42
end program test


Readelf looks as follows:

 [   12f]    subprogram
...
             sibling              (ref4) [   1a5]
 [   153]      imported_module
               decl_file            (data1) 1
               decl_line            (data1) 11
               import               (ref4) [   1a5]
 [   15a]      imported_module
               decl_file            (data1) 1
               decl_line            (data1) 10
               import               (ref4) [   1cb]
               sibling              (ref4) [   171]
 [   165]        imported_declaration
                 decl_file            (data1) 1
                 decl_line            (data1) 10
                 name                 (strp) "myvar"
                 import               (ref4) [   1d6]
Comment 8 Tobias Burnus 2011-06-25 08:13:38 UTC
GDB patch by Jan:
  http://sourceware.org/ml/gdb-patches/2011-06/msg00378.html
Comment 9 Tobias Burnus 2011-06-27 16:54:03 UTC
(In reply to comment #7)
> My impression is that this is a bug in GDB and not in GCC

Thus, the original problem has been fixed at some point. (I think it was Jakub's 
2008-08-29 commit.)

Any recent FSF gdb should should be able to print module variables using the <module>::<var> syntax - or directly the variable if one uses use-association. I am not sure whether 7.2 handles it already or whether the 7.3 (branched, to be released soon) is required. (Maybe 7.1 already did?)

Regarding the rename issue of comment 6: As written in comment 7/comment 8: That's a GDB issue for which a patch exists (to be committed in the next hours).

Thus, I close the PR now as FIXED. Please reopen - or fill a new PR with CCing me - if a related/new issue pops up.