[PATCH,fortran]: Emit COMMON identifiers in proper debug scope

[George Helffrich]

Dear Francois-Xavier -

	Thanks for your response.  Sorry your experience was unsatisfactory.   
There are two things going on here:  1) .stabs working or no; 2) DWARF  
working or no.

	I'll respond first to (1).  Your test program works fine on my system  
-- read on.

	The reason that this patch does not entirely fix .stabs debug problems  
for you is because there is an associated problem in gcc itself in the  
way it emits .stabs for COMMON symbols.  I proposed and got approved a  
patch to gcc to fix it -- here is the link (note date was Aug. 2004)

http://gcc.gnu.org/ml/gcc-patches/2004-08/msg02475.html

but, sadly, the patch was never committed to the gcc trunk, and the  
problem still persists three years on.

	Briefly, the problem is that on some systems, symbol references in  
assembler .stabs pseudo-ops are not relocated by the linker.  (One  
notable system is Darwin, which I use most, and for which I developed  
the patch.  Your system appears also to be one of this type.)  For  
identifiers located in COMMON, the .stabs debug information generates  
symbol references like __BLNK__+4.  The fix is to use an alternate  
.stabs encoding scheme for COMMON symbols that does not rely on  
linker-mediated relocation.  I can provide references to it if you are  
interested, but more importantly, I have a patch to the present gcc-4.3  
trunk that fixes the problem.  I haven't yet submitted the patch to  
gcc-patches (but will tomorrow if time permits).  There is no reason to  
link the two patches -- they are logically different problems, though  
they both affect Fortran debuggability.

	From your message, it looks like your system also suffers from the  
same non-relocation behavior for .stabs, so I can give you a prerelease  
of the gcc-4.3 patch if you want to verify that the change is truly a  
fix.  The gcc patch is against the gcc-4.3-20070810 snapshot, under  
which gfortran compiles.

	(2) could be a genuine problem that I could investigate if I had a  
DWARF capable system, but 8.8.0 Darwin isn't one of them:  voila

> #gfortran -v -gdwarf-2 -o x x.f90
> Driving: gfortran -mmacosx-version-min=10.4 -v -gdwarf-2 -o x x.f90  
> -lgfortranbegin -lgfortran -shared-libgcc
> Using built-in specs.
> Target: powerpc-apple-darwin8.8.0
> Configured with: ../gcc-4.3-20070810/configure  
> --enable-languages=fortran
> Thread model: posix
> gcc version 4.3.0 20070810 (experimental)
>  /usr/local/libexec/gcc/powerpc-apple-darwin8.8.0/4.3.0/f951 x.f90  
> -fPIC -quiet -dumpbase x.f90 -mmacosx-version-min=10.4 -auxbase x  
> -gdwarf-2 -version -fintrinsic-modules-path  
> /usr/local/lib/gcc/powerpc-apple-darwin8.8.0/4.3.0/finclude -o  
> /var/tmp//ccHVRl2E.s
> GNU F95 version 4.3.0 20070810 (experimental)  
> (powerpc-apple-darwin8.8.0)
>         compiled by GNU C version 4.3.0 20070810 (experimental), GMP  
> version 4.2.2, MPFR version 2.3.0-p3.
> GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
>  as -arch ppc -o /var/tmp//cc1lE1PT.o /var/tmp//ccHVRl2E.s
>  /usr/local/libexec/gcc/powerpc-apple-darwin8.8.0/4.3.0/collect2  
> -dynamic -arch ppc -macosx_version_min 10.4 -multiply_defined suppress  
> -weak_reference_mismatches non-weak -o x -lcrt1.o  
> /usr/local/lib/gcc/powerpc-apple-darwin8.8.0/4.3.0/crt3.o  
> -L/usr/local/lib/gcc/powerpc-apple-darwin8.8.0/4.3.0  
> -L/usr/local/lib/gcc/powerpc-apple-darwin8.8.0/4.3.0/../../..  
> /var/tmp//cc1lE1PT.o -lgfortranbegin -lgfortran -lgcc_s.10.4 -lgcc  
> -lSystemStubs -lSystem
> /usr/bin/ld: warning can't open dynamic library: /libgcc_s.1.dylib  
> referenced from:  
> /usr/local/lib/gcc/powerpc-apple-darwin8.8.0/4.3.0/../../../ 
> libgfortran.dylib (checking for undefined symbols may be affected) (No  
> such file or directory, errno = 2)
>
> #gdb x
> GNU gdb 6.3.50-20050815 (Apple version gdb-573) (Fri Oct 20 15:54:33  
> GMT 2006)
> 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 "powerpc-apple-darwin"...Reading symbols  
> for shared libraries .... done
>
> warning: Could not find object file "/private/var/tmp/ccpidWtg.o" - no  
> debug information available for "x.f90".
>
>
> (gdb) quit

I can eyeball the DWARF in a .s file, but don't think I can effectively  
check it with gdb.  I will happily co-debug with a willing DWARF-able  
collaborator.

On 28 Oct 2007, at 14:23, FX Coudert wrote:

> Hi George,
>
> First, thanks for contributing! The current state of the debug info  
> emitted by gfortran is far from very good (not to mention work  
> required on gdb to make it understand Fortran better), so we're always  
> happy to fix this.
>
>> This patch fixes scope bug arising with Fortran symbols defined in  
>> COMMON.  They get emitted in the wrong debug scope unless they are  
>> put on the symbol list associated with each function.  Bug shows up  
>> with stabs-type debug information and fixes that; other debug forms  
>> possibly also a problem.  Patch follows:
>
> Unfortunately, I don't think we can apply this patch as such. For the  
> following simple code:
>
> $ cat x.f90
> program test
>   integer ii, jj
>   common /foo/ ii,jj
>
>   ii = 42
>   jj = ii / 2
>   print *, ii, jj
>   call sub
> end program test
>
> subroutine sub
>   integer aa, bb
>   common /foo/ aa,bb
>   print *, aa, bb
> end subroutine sub
>
> the current situation with DWARF is fairly satisfying (I set  
> breakpoints on each of the "print" lines):
>
>> Breakpoint 1, MAIN__ () at x.f90:7
>> 7         print *, ii, jj
>> Current language:  auto; currently fortran
>> (gdb) p ii
>> $1 = 42
>> (gdb) p jj
>> $2 = 21
>> (gdb) c
>> Continuing.
>>           42          21
>>
>> Breakpoint 2, sub_ () at x.f90:14
>> 14        print *, aa, bb
>> (gdb) p aa
>> $3 = 42
>> (gdb) p bb
>> $4 = 21
>> (gdb) c
>> Continuing.
>>           42          21
>
> while for stabs+, it's not working at all:
>
>> Breakpoint 1, MAIN__ () at x.f90:7
>> 7         print *, ii, jj
>> (gdb) p ii
>> Address of symbol "ii" is unknown.
>> (gdb) p jj
>> No symbol "jj" in current context.
>> (gdb) p aa
>> $1 = 0
>> (gdb) p bb
>> $2 = 1431662116
>> (gdb) c
>> Continuing.
>>           42          21
>>
>> Breakpoint 2, sub_ () at x.f90:14
>> 14        print *, aa, bb
>> (gdb) p aa
>> $5 = 0
>> (gdb) p bb
>> $6 = 1431662116
>> (gdb) p ii
>> Address of symbol "ii" is unknown.
>> (gdb) p jj
>> No symbol "jj" in current context.
>> (gdb) c
>> Continuing.
>>           42          21
>
> With your patch added, it partly fixes stabs+ (partly only: see how  
> neither i nor a are displayed ok):
>
>> Breakpoint 1, MAIN__ () at x.f90:7
>> 7         print *, ii, jj
>> (gdb) p ii
>> Address of symbol "ii" is unknown.
>> (gdb) p jj
>> $1 = 21
>> (gdb) p aa
>> $2 = 0
>> (gdb) p bb
>> $3 = 1431662116
>> (gdb) c
>> Continuing.
>>           42          21
>>
>> Breakpoint 2, sub_ () at x.f90:14
>> 14        print *, aa, bb
>> (gdb) p ii
>> Address of symbol "ii" is unknown.
>> (gdb) p jj
>> No symbol "jj" in current context.
>> (gdb) p aa
>> $4 = 0
>> (gdb) p bb
>> $5 = 21
>> (gdb) c
>> Continuing.
>>           42          21
>
> But it breaks DWARF:
>
>> Breakpoint 1, MAIN__ () at x.f90:7
>> 7         print *, ii, jj
>> Current language:  auto; currently fortran
>> (gdb) p ii
>> No symbol "ii" in current context.
>> (gdb) p jj
>> No symbol "jj" in current context.
>> (gdb) p aa
>> $1 = 0
>> (gdb) p bb
>> $2 = 1431662116
>> (gdb) c
>> Continuing.
>>           42          21
>>
>> Breakpoint 2, sub_ () at x.f90:14
>> 14        print *, aa, bb
>> (gdb) p aa
>> $3 = 0
>> (gdb) p bb
>> $4 = 1431662116
>> (gdb) p ii
>> No symbol "ii" in current context.
>> (gdb) p jj
>> No symbol "jj" in current context.
>> (gdb) c
>> Continuing.
>>           42          21
>
> So, while I agree that the current behaviour is not good for stabs and  
> not perfect for dwarf (because the scope of common variables is too  
> large, ie we can access aa and bb in the main program, where they  
> don't belong), I think it's more complicated than that. I'm fairly new  
> to this debug info issues (I started understanding dwarf, and haven't  
> yet done anything on stabs), so I'm not sure what is happening there,  
> but maybe you have an idea?
>
> Regards,
> FX
>
>

                                                                          
      George Helffrich