Hi, I'm having a problem using gdb to debug code compiled with gfortran (v 4.3.0). The code: program test i = 1 C Breakpoint here end when compiled with "gfortran -gstabs -o prog prog.f", debugged with "gdb prog" demonstrates the error. The commands: (gdb) break 3 (gdb) run produces the output: > Starting program: /private/tmp/prog > Reading symbols for shared libraries .++ done > > Breakpoint 1, main (argc=1, argv=0xbfffe9b8) at ../../../gcc-4.3-20070810/libgfortran/fmain.c:12 > 12 ../../../gcc-4.3-20070810/libgfortran/fmain.c: No such file or directory. > in ../../../gcc-4.3-20070810/libgfortran/fmain.c At this point commands to examine symbols fail: (gdb) display i No symbol "i" in current context. The problem is the same on a PowerPC machine also.
The problem is that you end up in the wrong file. If you enter "break 3" you are debugging the wrapping program not the Fortran "program test", which is the reason that there is no "i" available. Try: break file.f:line, e.g. (gdb) b b.f:2 However, there is another problem: One cannot set the break point after the assignment: program test ! Breakpoint possible i = 1 ! Breakpoint possible ! Breakpoint here ! No breakpoint possible end ! No breakpoint possible Setting a breakpoint in line 2, one can print the value "i" before the assignment; however, doing a "step" one ends in the wrapping main() program and can thus never read the value after the assignment. Using g77 or ifort, one can set a break point in line 3 or 4 and gdb shows then: Breakpoint 1, test () at b.f:4 4 end
(In reply to comment #1) > The problem is that you end up in the wrong file. If you enter "break 3" you > are debugging the wrapping program not the Fortran "program test", which is the > reason that there is no "i" available. This part of the bug was fixed by a recent commit of mine (and a gdb patch). With development versions of gfortran and gdb, breaking by "b 2" will break at line 2 of the Fortran main program. > However, there is another problem: One cannot set the break point after the > assignment: > > program test ! Breakpoint possible > i = 1 ! Breakpoint possible > ! Breakpoint here ! No breakpoint possible > end ! No breakpoint possible It's also possible in C with GCC mainline: (gdb) l 1 int main(void) 2 { 3 int i; 4 i = 1; 5 /* That's all, folks! */ 6 } (gdb) b 5 Breakpoint 1 at 0x400467: file z.c, line 5. (gdb) r Starting program: /home/fxcoudert/devel/debug2/irun/a.out Breakpoint 1, main () at z.c:6 6 }
I have a patch for this. Note, however, that the compiler - even with default options - (too) aggressively optimizes your program, i.e. the assignment is optimized away even with -O0 and thus for your program the value is alway some random value. (This is also the the case for the analogous C program - if you think it should be fixed, please fill a middle-end bug.) If you do: subroutine test save ! or actual argument or in common or ... i = 1 ! Breakpoint here ! a break point here becomes a b. in the next line end subroutine test ! <<< the breakpoint can be set to this line with my patch, it properly prints the value "1" for "i" after the assignment.
Subject: Bug 34153 Author: burnus Date: Wed May 13 14:52:54 2009 New Revision: 147477 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147477 Log: 2009-05-13 Tobias Burnus <burnus@net-b.de> PR fortran/34153 * gfortran.h (gfc_exec_op): Add EXEC_END_PROCEDURE. * dump-parse-tree.c (show_code_node): Use EXEC_END_PROCEDURE. * trans.c (gfc_trans_code): Ditto. * resolve.c (resolve_code): Ditto. * st.c (gfc_free_statement): Ditto. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/dump-parse-tree.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/parse.c trunk/gcc/fortran/resolve.c trunk/gcc/fortran/st.c trunk/gcc/fortran/trans.c
FIXED on the trunk (4.5). Thanks for the bug report!