Re: gdb and g77

[craig at jcb-sc dot com]

>I don't think there was any question about whether or not the ordering in
>memory was correct -- only questions about why g77 & gdb aren't cooperating
>well.

Well, from my point of view, there *was* a question, in that, if the
bug was in the g77 front end, I couldn't see how it'd *not* be doing
something so wrong we would have detected it even without debugging
being involved.  So that suggests, to me, the problem isn't in the
front end.

>So, let's walk through the problem.  I see two cases worth examination:
>
>  1. gcc emits incorrect debug records.
>
>  2. gdb interprets the debug records incorrectly.

But we now have info suggesting that gdb interprets debug records
from Fortran compilers *other* than g77 (with back ends other than
gcc, I assume) *correctly*.

>A quick review of dbxout.c & dwarf2out.c leads me to believe that neither is
>reversing the subscripts.  However, we should make sure by examining the
>debug records created for a simple 2-d array.

Yup.  I don't know what various debug formats should look like, especially
in the area of multi-dimensional arrays.

>We should also review the stabs & dwarf2 specs to make sure they do not
>specify something dumb like requiring the compiler to emit records with
>reversed subscripts :-)

Indeed.  Reviewing the specs is one of the requirements for working on
this -- which is why I haven't just dived into the code yet, I've got
too many *other* things to review at the moment!

So I'd very much appreciate anyone with some understanding (and time)
helping find the culprit....

I wouldn't say this is *quite* a "must fix" for 2.95, since it's presumably
not a regression.  But that (flow?) bug that results in gdb letting the
first statement in a routine run before the breakpoint on that routine
name "catches", *that* I would call a "blocking bug", or nearly so.

        tq vm, (burley)