[Bug fortran/29937] New: Stepping Fortran(77) code always jumps back to subroutine header

[Bug fortran/29937] New: Stepping Fortran(77) code always jumps back to subroutine header

[andreemalcher at gmail dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=29937

            Bug ID: 29937
           Summary: Stepping Fortran(77) code always jumps back to
                    subroutine header
           Product: gdb
           Version: 8.2
            Status: UNCONFIRMED
          Severity: minor
          Priority: P2
         Component: fortran
          Assignee: unassigned at sourceware dot org
          Reporter: andreemalcher at gmail dot com
  Target Milestone: ---

I have a rather large code base (proprietary) including F77, C and C++ code.
The F77 parts are compiled with gfortran 11.2.0.

Compiling with debugging symbols and running the application with gdb works
fine so far, but for the Fortran part there is the following annoyance:

For every `next` step in gdb, the debugger jumps to the corresponding
subroutine header and I need to enter `next` again to go the the actual next
line/statement. Consider the following snippet from a gdb session:

```
843           DELTA = TIME - TOLD
(gdb) n
97            SUBROUTINE THE_SUBROUTINE_HEADER
(gdb) n
844           DELOLD(1) = DELTA
(gdb) n
845           CALL COMCOF
(gdb) n
97            SUBROUTINE THE_SUBROUTINE_HEADER
(gdb) n
854           IF (ITL5 .NE. 0 .AND.
(gdb) n
97            SUBROUTINE THE_SUBROUTINE_HEADER
(gdb) n
854           IF (ITL5 .NE. 0 .AND.
```

I hope the point is clear. While I just want to step line by line through the
code, I always have a superfluous step to `SUBROUTINE THE_SUBROUTINE_HEADER`,
as also evident when looking at the line numbers. 

A few remarks:

* Interestingly, for logical operators, it looks like for every operand I have
these additional calls (i.e. if I have something like `IF (A .AND. B .AND. C)`,
gdb will jump to the subroutine header three times).

* The problem doesn't show up with the `advance` command, i.e. if I type
`advance 900` to advance to line 900 in the example above, gdb will happily
fast forward to the given location.

* FWIW, this also happens when I run the debugger from an IDE (that is, using
GDB/MI)

* The C and C++ code is not affected, there gdb works like expected (in the
same session).

* A related question was posted on StackOverflow, but no replies have been
posted so far:
https://stackoverflow.com/questions/23744141/ddd-execution-line-jumps-to-subroutine-top-continuation-line-fortran-77

Unfortunately I am not able to reproduce this bug in a small test program. 

Last but not least, things I have tried in the original program:
* Try with gdb 10.1 and 11.1 (the latter has its own set of problems, e.g.
stepping takes ages to complete)
* Delete/remove everything from my ~/.gdbinit
* remove all flags except for `-g -O0`
* try with `-g3`
but to no avail.

Let me know in case you need further information or want me to test something,
I'll be happy to help.

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug fortran/29937] Stepping Fortran(77) code always jumps back to subroutine header

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=29937

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
> For every `next` step in gdb, the debugger jumps to the corresponding subroutine
> header and I need to enter `next` again to go the the actual next line/statement.

Normally this kind of thing turns out to be a problem in the debuginfo,
and not in gdb.

Sometimes you can see this by using "disassemble/s" on the
function in question.  Otherwise, where I would normally start is
by examining the line table with "readelf -wL".

-- 
You are receiving this mail because:
You are on the CC list for the bug.