Re: gdb bug in Fortran langauge mode

[craig at jcb-sc dot com]

[bug-gdb people: This is just follow-up on a previous g77-related gdb bug
report I submitted the other day.]


>Craig notes that the 'whatis' command of gdb produces the correct
>result.  This is because gdb's 'whatis' command is buggy-- it prints
>the array elements in the wrong order!

As Jeff pointed out, this is not clear.

Andy, it's not that we don't believe you per se.

The main problem is, I don't know what the stabs format mandates for
array ordering for Fortran *specifically*, but what it mandates
*generally* is, in fact, what g77/gcc are correctly providing.

*But*, what I *do* know is, there is *no reason* for *any* low-level
system like this to mandate a *different* ordering for Fortran than
it does for C.

In other words, any design that says "encode subscript information
backwards for Fortran" is inherently *broken* in the sense that the
different ordering is visible only to the *user*, or *programmer*,
not the lower-level facilities.

For example, as I and others have pointed out, what the gcc back end
sees, in terms of multiple-dimension arrays, is *always* ordered the
same, regardless of the original language.  It is up to the front
end to convert that "natural" ordering (natural due to the Polish-notation-
ish tree representation) from whatever source-level conventions it
supports.

Therefore, given that the back end will see "variable of type array
(size 5) of type array (size 4) of type array (size 3) of type REAL"
for "REAL A(3,4,5)", there's no reason to, *downstream* from that,
change the ordering.

Of course, when a downstream program like gdb does *language-level*
representation, *it* has to reverse ordering for *that* one purpose,
e.g. reverse the order for `whatis' output and for `p a(2,2,2)' input.

But, at *that* point, there's *clearly* a need to know exactly what the
language is, just as there is when the g77 front end parses the source
code for the program.

In between the g77 front end and the gdb expression/command parser,
there is *no* need (conceptually) to know that the source language
is Fortran.

Therefore, there's *no* need to require that those intermediate phases
must support gratuitously different encodings of information on the
grounds that "it's Fortran".

The upshot: unless stabs *clearly* defines the array information for
Fortran as reversed from the normal array information, g77 and gcc
are *correct* in their current treatment.  (And if the consensus was
that, yes, stabs format was defined to treat Fortran differently,
then we'd have to conclude that the designers of stabs really botched
this issue, but we'd have to "fix" g77/gcc to obey the botch.)

And, I've just read the GNU Info documentation on `stabs', and, despite
documenting all sorts of anomalies, questions, and Fortran-related
issues, there's not a single mention of a special ordering for Fortran
arrays.  (The document does not appear to have version information on
it; it came with my Redhat 5.2 Linux system, I presume.)

Conclusion: g77/gcc are working properly, vis-a-vis stabs format anyway,
so it is gdb needs to be fixed.  (Unfortunately, since that probably
means some kind of "flag day" for vendors of some other compilers,
who've worked around this gdb bug, and perhaps even copied it into their
own debuggers, though gdb might have copied it *out* of some others.)

        tq vm, (burley)