Re: Using g77 and gdb together

[craig@jcb-sc.com]

>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)