Using g77 and gdb together

[Gerard Flynn]

craig@jcb-sc.com wrote:

> >In particular gdb seems to be confused about source line numbers.  For
> >exemple there exists a subroutine called amorti_ (AMORTI) in a given
> >source
> >file.  The line number of the subroutine statement is 498 and the first
> >executable statement is an IF at line 528 followed by an assignment at
> >529.
> >
> >Now if in gdb I type:
> >> break amorti_
> >I see:
> >Breakpoint 2 at 0x80c65be: file ../beta/source/emequi.f, line 648.
> >
> >Line 648 is the RETURN statement at the end of the routine.
> >
> >If I type
> >> list amorti_
> >
> >gdb lists lines between 582 and 591, somewhere in the middle of the
> >routine.
> >
> >The source file in question makes use of many INCLUDE statements some of
> >which are nested.  The include files, source files
> >and executable are all in separate directories.  It also contains
> >routines containing
> >ENTRY statements (although the particular routine I mentioned here does
> >not.).
>
> Hmm.  Many possible problems here.
>
> First, make sure you compile with `-g -O0' to turn off optimization,
> at least until you verify that this produces some reasonable gdb-time
> behavior.
>
> Now, there are several known problems with g77+gdb, some of which are
> not perhaps well-understood:
>
>   -  I think GCC 2.95 (thence g77 0.5.25) still has the "skidding break"
>      bug I reported a couple of months back.  The symptom of this bug
>      is that when you break on a procedure (C "function") by name, rather
>      than stop *before* the first executable statement, sometimes the
>      debugger stops after it (i.e. before the second one).
>
>      IIRC, this is not a gdb bug, and it was discussed and suggested
>      was due to recent changes in flow.c.  It's pretty easy to reproduce
>      with a small test case.
>
>   -  g77 does have some problems (I think documented at least somewhat
>      in the known-bugs section of the manual) tracking source line numbers
>      across #include, INCLUDE, or both.  It's probably the case that my
>      view regarding this problem has been limited to its effect on
>      diagnostics, and that it also affects line-number info provided for
>      debuggers to track.  I'm pretty sure the problem (which I think I
>      "scoped out" some two years ago!) is entirely g77-specific.
>
> If you study the output of using `-g -S' when compiling pertinent code,
> you might learn ways to fix some of the above problems sufficiently to
> at least demonstrate whether your problems are entirely due to one or
> both of the above, versus some other problems.
>
>         tq vm, (burley)

It looks like the problem is coming from the nested INCLUDE "feature" of
the program I'm working on.  Here's a simple test case which produces odd
behavior:

file BIDON.H :
      INCLUDE 'BIDON1.H'
      INCLUDE 'BIDON2.H'

file BIDON1.H :
      REAL R1
      REAL R2
      REAL R3
      REAL R4
      REAL R5
      REAL R6
      REAL R7

file BIDON2.H :
      INTEGER I1
      INTEGER I2
      INTEGER I3
      INTEGER I4
      INTEGER I5
      INTEGER I6
      INTEGER I7

file complex.f :
      PROGRAM TCMPLX
      IMPLICIT NONE

      INCLUDE 'BIDON.H'

      DOUBLE PRECISION A,B,C,D
      COMPLEX*16 CX,CY,CZ
      DOUBLE PRECISION V
      DIMENSION V(7,35)
      DOUBLE PRECISION TETAD,ROD,AK,W
      COMPLEX*16 VQ,VX,VXP,VD

      A=1.0D0
      B=2.0D0
      C=3.0D0

      CY = DCMPLX(5.6D0)
      CZ = DCMPLX(7.8D0)

C      CX = A*CY + B*CZ

      WRITE(*,*) 'POSITION 1'
      W = 1.33517999
      VQ = (6.04309754E-16,9.75346765E-5)
      V(5,2) = 0.497920662
      VX = (0.790273955,0.567044628)
      WRITE(*,*) 'POSITION 2'
      ROD = 1.70000005
      AK = 1.70000005
      TETAD = 0.785399973
      V(5,1) = 0.707108061
      WRITE(*,*) 'POSITION 3'
      VXP = (-1.39827846,-0.370613616)
      VD = (0.0,0.0)

      CX=(W*VQ + V(5,2)*VX + ROD*AK*(TETAD-V(5,1))*VXP) * DCONJG(VD)

C      CX = (W*VQ + V1*VX + ROD*AK*(TETAD-V2)*VXP)*DCONJG(VD)
C      CX = (W*VQ + V(5,2)*VX + ROD*AK*(TETAD-V(5,1))*VXP) * DCONJG(VD)

      WRITE(*,*) 'CX = ',CX

      END

If you try putting break points in this program based on line numbers and
then running it,
you'll probably fall of the end.  In addition gdb is showing the same address
for breakpoints
at 3 different source positions !

Gerard Flynn