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)

If I compare the output of gcc -g -S on the files I posted with and without
commenting of the INCLUDE line, the .stabn line number lines are
different between the two cases.  If these numbers are intended to refer
to the original source file then this would seem incorrect.

More specifically, if the INCLUDE line is commented then the first
two line number indications are :

.stabn 68,0,1,.LM1-MAIN__

followed by :

.stabn 68,0,13,.LM3-MAIN__.

If the INCLUDE is uncommented the second such line becomes :

.stabn 68,0,29,.LM3-MAIN__.

The total number of included lines is 14 so the difference doesn't correspond

exactly but it's close.

Gerard Flynn