If I compile the following program with -gstabs+ under OSX 10.5.5 with gcc4.4 Using built-in specs. Target: i386-apple-darwin8.10.1 Configured with: /tmp/gfortran-20081006/ibin/../gcc/configure --prefix=/usr/local/gfortran --enable-languages=c,fortran --with-gmp=/tmp/gfortran-20081006/gfortran_libs --enable-bootstrap Thread model: posix gcc version 4.4.0 20081006 (experimental) [trunk revision 140904] (GCC) program hello integer a common /testcommon/a integer pos(3) a = 5 pos(1) = 2 pos(2) = 1 pos(3) = 1 write (*,*) "HELLO", A end as follows: gfortran -gstabs+ -o testcase testcase.f Then I can correctly use gdb as shown below: Breakpoint 1, MAIN__ () at testcase.f:1 1 program hello (gdb) next Current language: auto; currently fortran 8 a = 5 (gdb) list 3 integer a 4 common /testcommon/a 5 6 integer pos(3) 7 8 a = 5 9 10 pos(1) = 2 11 pos(2) = 1 12 pos(3) = 1 However, if I compile with -finit-local-zero like this: gfortran -finit-local-zero -gstabs+ -o testcase testcase.f The line numbers don't match the source code as shown below: Breakpoint 1, MAIN__ () at testcase.f:1 1 program hello (gdb) next Current language: auto; currently fortran 6 integer pos(3) (gdb) list 1 program hello 2 3 integer a 4 common /testcommon/a 5 6 integer pos(3) 7 8 a = 5 9 10 pos(1) = 2 (gdb) quit The compiler is apparently adding extra code to initizilize the variables but not accounting for it in the line numbers. This problem has existed as long as the -finit-local-zero option has been avaliable in gfortran. I can't test other -g options as they don't generate usuable debug information on OSX.
> I can't test other -g options as they don't generate > usuable debug information on OSX. To my knowledge OS X also supports DWARF debugging symbols, cf. http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00745.html However, with DWARF the result is the same. > The line numbers don't match the source code as shown below: I might miss something, but the line numbers look OK. > The compiler is apparently adding extra code to initizilize > the variables but not accounting for it in the line numbers. It does and seemingly the debug location used for this is the line of the last variable declaration. It is actually not quite clear how gfortran should handle this - simply not allowing a break point in line 6? Or ... ?
To me the initialization of the variables should be recorded when using -finit-local-zero.
In fact g77 did the same, see PR 15171.
> To my knowledge OS X also supports DWARF debugging symbols, cf. > http://gcc.gnu.org/ml/gcc-patches/2007-02/msg00745.html Hmm.. Well when I try it I get (using gfortran -gdwarf-2) this when I start gdb: GNU gdb 6.3.50-20050815 (Apple version gdb-960) (Sun May 18 18:38:33 UTC 2008) 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-apple-darwin"...Reading symbols for shared libraries .... done warning: Could not find object file "/var/folders/7c/7cla3UxyGe0s8EeGsHNlUU+++TI/-Tmp-//cc8EVMgS.o" - no debug information available for "testcase.f". > > I might miss something, but the line numbers look OK. > > > > The compiler is apparently adding extra code to initizilize > > the variables but not accounting for it in the line numbers. > > It does and seemingly the debug location used for this is the line of the last > variable declaration. Well... As described in the closed bug report the effect is a lot of jumping around among the declaration statements for more complicated code. It steps in both directions (I mean it will go from line 6 to 2 to 7 etc etc) I assumed this was a problem but it sounds like you are saying these are the lines that correspond to the assembly code. If it is always the case that there is really a one-to-one correspondence between the source line and what is being cleared it makes sense if you understand it. My feeling is that the code that the compiler adds to clear the variables is different than what is in the source code (which are definitions) so it shouldn't be trying to step through that source code. The variable definition isn't really the same as clearing the variable. I don't remember ever seeing this when debugging in g77 on linux but I take your word for it. Perhaps it shouldn't be changed but it is very confusing as it is quite difficult to tell when the subroutine execution ever begins. In anycase, I understand your explanation if you would rather not change it. It might be worth adding a warning to the documentation. Thanks.
IMHO we should just not put a locus on the generated code to zero out the variable at the start of the (sub-)program.
AFAICT -gstabs+ is no longer supported on OSX. The PR is more than ten year old and I don't understand what is the expected behavior. Should not it be closed as FIXED or WORKSFORME?
Enhancement for old debug info format, old compiler, etc. => wontfix.