This is the mail archive of the fortran@gcc.gnu.org mailing list for the GNU Fortran project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]