Re: gdb bug in Fortran langauge mode

Re: gdb bug in Fortran langauge mode

[David Taylor]

    Date: Wed, 16 Jun 1999 17:05:39 -0700
    From: Stan Shebs <shebs@cygnus.com>

       Date: Wed, 16 Jun 1999 17:31:14 -0600
       From: Jeffrey A Law <law@cygnus.com>

       It is unfortunate that stabs do not explicitly state how Fortran should be
       handled

    Is this still true?  I must confess I don't have a copy of Sun's
    official stabs book (SPARCworks 3.0.x Debugger Interface), which I
    believe postdates the GNU stabs doc, and which I've heard clarifies
    many obscure points.

Unless things have changed, Sun considers their stabs stuff to be
proprietary and it's available to customers only under non disclosure.

Re: gdb bug in Fortran langauge mode

[Dave Love]

>>>>> "DT" == David Taylor <taylor@cygnus.com> writes:

 DT> Unless things have changed, Sun considers their stabs stuff to be
 DT> proprietary and it's available to customers only under non
 DT> disclosure.

Well, I have in front of me a copy of the doc I referred to before,
from a Sun compiler distribution: `SPARCworks 3.0.x Debugger
Interface', dated 1994.  docs.sun.com is sulking when I try to check
there.

Re: gdb bug in Fortran langauge mode

[David Taylor]

    Date: Wed, 16 Jun 1999 17:05:39 -0700
    From: Stan Shebs <shebs@cygnus.com>

       Date: Wed, 16 Jun 1999 17:31:14 -0600
       From: Jeffrey A Law <law@cygnus.com>

       It is unfortunate that stabs do not explicitly state how Fortran should be
       handled

    Is this still true?  I must confess I don't have a copy of Sun's
    official stabs book (SPARCworks 3.0.x Debugger Interface), which I
    believe postdates the GNU stabs doc, and which I've heard clarifies
    many obscure points.

Unless things have changed, Sun considers their stabs stuff to be
proprietary and it's available to customers only under non disclosure.

Re: gdb bug in Fortran langauge mode

[Dave Love]

>>>>> "DT" == David Taylor <taylor@cygnus.com> writes:

 DT> Unless things have changed, Sun considers their stabs stuff to be
 DT> proprietary and it's available to customers only under non
 DT> disclosure.

Well, I have in front of me a copy of the doc I referred to before,
from a Sun compiler distribution: `SPARCworks 3.0.x Debugger
Interface', dated 1994.  docs.sun.com is sulking when I try to check
there.

Re: gdb bug in Fortran langauge mode

[craig]

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

Re: gdb bug in Fortran langauge mode

[Andy Vaught]

>Could whoever asserted that gdb works with "other" Fortran's please
>submit a complete example of this working, including the source code
>for a small Fortran program, the gdb session showing it working, and
>the assembler output of the "other" compiler when compiling that
>program, so we can see for ourselves just what "working" means in this
>case?


Start with the test program:

---------------
      program foo
      dimension array(3,4,5)

      array(1,1,1) = 1

      end
---------------

On i86, I compiled with: 'g77 -c -g badsym.f'

'objdump --stabs badsym.o' gives, in part:

57     LSYM   0      3      ffffff10 2373   array:(0,47)=ar(0,20);1;5;(0,48)=ar(0,20);1;4;(0,49)=ar(0,20);1;3;(0,32)

You can see that the last array element is first in the stab.  Now try
it on an RS6K, using the XLF compiler.  'objdump --syms badsym.o'
produces:


[ 15](sec -2)(fl 0x00)(ty   0)(scl 142) (nx 0) 0x00000000 foo:F-11
[ 16](sec  1)(fl 0x00)(ty   0)(scl 101) (nx 1) 0x00000014 .bf
AUX lnno 5 size 0x0 tagndx 0
[ 18](sec  3)(fl 0x00)(ty   0)(scl 143) (nx 0) 0x0000001e .bs
[ 19](sec -2)(fl 0x00)(ty   0)(scl 140) (nx 0) 0x00000000 :t5=ar0;1;3;ar0;1;4;ar0;1;5;-12
[ 20](sec -2)(fl 0x00)(ty   0)(scl 133) (nx 0) 0x00000000 array:V5
[ 21](sec  3)(fl 0x00)(ty   0)(scl 144) (nx 0) 0x00000000 .es
[ 22](sec  1)(fl 0x00)(ty   0)(scl 101) (nx 1) 0x00000030 .ef

Here we see that the first array element is emitted first, and so on.


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!

Looking at the gdb code that calculates the addresses of array
elements shows that they are computed in reverse order of how the
'whatis' commands prints them.  If we start from here, gdb is clearly
wrong at some point-- either the 'whatis' is backwards or address
calculation is backwards.

To resolve the problem, I ran gdb on a program compiled by IBM's XLF
compiler.  The array printing works fine and the 'whatis' was backwards. 
On an i86 with g77, the array printing doesn't work and 'whatis' does. 

The answer is that gcc/g77 is emitting the debug info for array elements
in the wrong order.  The reason the 'whatis' works on a g77 program is
because things are reversed twice. 

The debugging dump between the XLF and g77 programs show that the array
info is being emitted in opposite orders.  Since XLF and gdb work fine
together (and XLF also works with the bundled dbx debugger), it follows
that g77/gcc is the one emitting debug info in the wrong order, and that
gdb's 'whatis' command prints them in the wrong order. 


        Andy

-----------------                        XOLD(K,IC,I)=
Andy Vaught               ....        DO ITERS=1, 10  XOLD(K,IC,I)
andy@maxwell.la.asu.edu   |  |   /CALLMSOLVE(A,B,X,I,ITERS,TOL)+(RANNYU(0)
Arizona State University  ======|WRITE(6,'(I5,2X,F12.6)')ITERS,TOL -HALF)
Tempe, Arizona USA        OOOOOO \ENDDORETURN PARAMETER(ZERO=1.D0)*TENTH*DELTA

Re: gdb bug in Fortran langauge mode

[Stan Shebs]

   Date: Wed, 16 Jun 1999 17:31:14 -0600
   From: Jeffrey A Law <law@cygnus.com>

   It is unfortunate that stabs do not explicitly state how Fortran should be
   handled

Is this still true?  I must confess I don't have a copy of Sun's
official stabs book (SPARCworks 3.0.x Debugger Interface), which I
believe postdates the GNU stabs doc, and which I've heard clarifies
many obscure points.

Unless we can show that, say, AIX Fortran and Sun f77, are inconsistent
with each other, and if it's not too hard to change g77 and GCC's
backend, I would recommend changing to be consistent with pre-existing
compilers.  Stabs already has enough random inconsistencies, it
doesn't help us to add more.

								Stan

Re: gdb bug in Fortran langauge mode

[Andy Vaught]

On 16 Jun 1999 craig@jcb-sc.com wrote:

> [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.

Well, have a look at the code.  The 'whatis' does a real weird recursion
thing, while the array-element address calculation uses the textbook
method reminiscient of Horner's method.

It still remains that g77 and xlf emit array info in opposite orders.  Gdb
reads those stabs to figure out the rank and shape of an array. 

If the gdb people implement what you are asking for, and reverse the
ordering of array elements, then printing array elements will break on
AIX/RS6k.  From what I recall, Sun invented the stabs format, not IBM, so
you can probably expect gdb to break on Sun's f77 as well.  The gdb people
are welcome to the patch I posted to gdb-patches months ago that does
exactly this.

Is there anyone out there on a Sun or different machine who can tell us
if gdb correctly prints elements of multidimensional fortran arrays?

     Andy


-----------------                        XOLD(K,IC,I)=
Andy Vaught               ....        DO ITERS=1, 10  XOLD(K,IC,I)
andy@maxwell.la.asu.edu   |  |   /CALLMSOLVE(A,B,X,I,ITERS,TOL)+(RANNYU(0)
Arizona State University  ======|WRITE(6,'(I5,2X,F12.6)')ITERS,TOL -HALF)
Tempe, Arizona USA        OOOOOO \ENDDORETURN PARAMETER(ZERO=1.D0)*TENTH*DELTA

Re: gdb bug in Fortran langauge mode

[Dave Love]

If you want information about the output of other compilers in
specific cases I can probably provide it again at some stage, at least
for SunPro, MIPSpro (?), IBM XL, DEC of some vintages.

I hope gdb won't sacrifice g77 support for other compilers, but I'm
pretty sure work needs to be done on both g77 and gdb anyway.  g77
debugging is hardly winning at the moment :-(.

Re: gdb bug in Fortran langauge mode

[Jeffrey A Law]

  In message < Pine.SGI.3.96.990615233907.730A-100000@maxwell.la.asu.edu >you wri
te:
  > it on an RS6K, using the XLF compiler.  'objdump --syms badsym.o'
  > produces:
One could just as easily claim the XLF compiler is backwards.  

  > 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!
Not necessarily.

  > To resolve the problem, I ran gdb on a program compiled by IBM's XLF
  > compiler.  The array printing works fine and the 'whatis' was backwards. 
  > On an i86 with g77, the array printing doesn't work and 'whatis' does. 
  > 
  > The answer is that gcc/g77 is emitting the debug info for array elements
  > in the wrong order.  The reason the 'whatis' works on a g77 program is
  > because things are reversed twice. 
No, if you read the earlier messages, I think you'll find that folks here
think that that the order is correct.

jeff

Re: gdb bug in Fortran langauge mode

[craig]

>Unless we can show that, say, AIX Fortran and Sun f77, are inconsistent
>with each other, and if it's not too hard to change g77 and GCC's
>backend, I would recommend changing to be consistent with pre-existing
>compilers.  Stabs already has enough random inconsistencies, it
>doesn't help us to add more.

Unfortunately, g77 has *also* been pretty long in existence, and has, to
date, generated "consistent" stabs format -- consistent in the sense
that it works the same regardless of whether the language mode is C
or Fortran, in gdb.

But, if there turns out to be One Right Way to do these stabs -- a
way that is, in fact, the *inconsistent* way -- and g77 is "odd man out",
then we can make the decision to change g77, and announce a "flag day"
for *our* users.

In other words, let's accommodate broken implementations only where
it's clear that they're broken *by design*, as would be the case
if the stabs info for multi-dimensional arrays was reversed "for
Fortran".

At this point, that certainly isn't clear.

        tq vm, (burley)

Re: gdb bug in Fortran langauge mode

[Jeffrey A Law]

  In message < Pine.SGI.3.96.990616152202.1469A-100000@maxwell.la.asu.edu >you wr
ite:
  > If the gdb people implement what you are asking for, and reverse the
  > ordering of array elements, then printing array elements will break on
  > AIX/RS6k.  From what I recall, Sun invented the stabs format, not IBM, so
  > you can probably expect gdb to break on Sun's f77 as well.  The gdb people
  > are welcome to the patch I posted to gdb-patches months ago that does
  > exactly this.
  > 
  > Is there anyone out there on a Sun or different machine who can tell us
  > if gdb correctly prints elements of multidimensional fortran arrays?
If other hosts do it one way, that does not necessarily make it correct.  How
other host/target combos handle this is but one factor in the decision about
what is right and what is wrong.

It is unfortunate that stabs do not explicitly state how Fortran should be
handled (though it's worth noting dwarf2 has bits to indicate how this stuff
works).    Then again, nobody has made a serious effort to definitively define
the stabs format.

And, err, Sun did not invest stabs.  stabs pre-date Sun's entry into the
workstation market.



jeff

Re: gdb bug in Fortran langauge mode

[Dave Love]

If you want information about the output of other compilers in
specific cases I can probably provide it again at some stage, at least
for SunPro, MIPSpro (?), IBM XL, DEC of some vintages.

I hope gdb won't sacrifice g77 support for other compilers, but I'm
pretty sure work needs to be done on both g77 and gdb anyway.  g77
debugging is hardly winning at the moment :-(.

Re: gdb bug in Fortran langauge mode

[craig]

>Unless we can show that, say, AIX Fortran and Sun f77, are inconsistent
>with each other, and if it's not too hard to change g77 and GCC's
>backend, I would recommend changing to be consistent with pre-existing
>compilers.  Stabs already has enough random inconsistencies, it
>doesn't help us to add more.

Unfortunately, g77 has *also* been pretty long in existence, and has, to
date, generated "consistent" stabs format -- consistent in the sense
that it works the same regardless of whether the language mode is C
or Fortran, in gdb.

But, if there turns out to be One Right Way to do these stabs -- a
way that is, in fact, the *inconsistent* way -- and g77 is "odd man out",
then we can make the decision to change g77, and announce a "flag day"
for *our* users.

In other words, let's accommodate broken implementations only where
it's clear that they're broken *by design*, as would be the case
if the stabs info for multi-dimensional arrays was reversed "for
Fortran".

At this point, that certainly isn't clear.

        tq vm, (burley)

Re: gdb bug in Fortran langauge mode

[Stan Shebs]

   Date: Wed, 16 Jun 1999 17:31:14 -0600
   From: Jeffrey A Law <law@cygnus.com>

   It is unfortunate that stabs do not explicitly state how Fortran should be
   handled

Is this still true?  I must confess I don't have a copy of Sun's
official stabs book (SPARCworks 3.0.x Debugger Interface), which I
believe postdates the GNU stabs doc, and which I've heard clarifies
many obscure points.

Unless we can show that, say, AIX Fortran and Sun f77, are inconsistent
with each other, and if it's not too hard to change g77 and GCC's
backend, I would recommend changing to be consistent with pre-existing
compilers.  Stabs already has enough random inconsistencies, it
doesn't help us to add more.

								Stan

Re: gdb bug in Fortran langauge mode

[Jeffrey A Law]

  In message < Pine.SGI.3.96.990616152202.1469A-100000@maxwell.la.asu.edu >you wr
ite:
  > If the gdb people implement what you are asking for, and reverse the
  > ordering of array elements, then printing array elements will break on
  > AIX/RS6k.  From what I recall, Sun invented the stabs format, not IBM, so
  > you can probably expect gdb to break on Sun's f77 as well.  The gdb people
  > are welcome to the patch I posted to gdb-patches months ago that does
  > exactly this.
  > 
  > Is there anyone out there on a Sun or different machine who can tell us
  > if gdb correctly prints elements of multidimensional fortran arrays?
If other hosts do it one way, that does not necessarily make it correct.  How
other host/target combos handle this is but one factor in the decision about
what is right and what is wrong.

It is unfortunate that stabs do not explicitly state how Fortran should be
handled (though it's worth noting dwarf2 has bits to indicate how this stuff
works).    Then again, nobody has made a serious effort to definitively define
the stabs format.

And, err, Sun did not invest stabs.  stabs pre-date Sun's entry into the
workstation market.



jeff

Re: gdb bug in Fortran langauge mode

[Andy Vaught]

On 16 Jun 1999 craig@jcb-sc.com wrote:

> [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.

Well, have a look at the code.  The 'whatis' does a real weird recursion
thing, while the array-element address calculation uses the textbook
method reminiscient of Horner's method.

It still remains that g77 and xlf emit array info in opposite orders.  Gdb
reads those stabs to figure out the rank and shape of an array. 

If the gdb people implement what you are asking for, and reverse the
ordering of array elements, then printing array elements will break on
AIX/RS6k.  From what I recall, Sun invented the stabs format, not IBM, so
you can probably expect gdb to break on Sun's f77 as well.  The gdb people
are welcome to the patch I posted to gdb-patches months ago that does
exactly this.

Is there anyone out there on a Sun or different machine who can tell us
if gdb correctly prints elements of multidimensional fortran arrays?

     Andy


-----------------                        XOLD(K,IC,I)=
Andy Vaught               ....        DO ITERS=1, 10  XOLD(K,IC,I)
andy@maxwell.la.asu.edu   |  |   /CALLMSOLVE(A,B,X,I,ITERS,TOL)+(RANNYU(0)
Arizona State University  ======|WRITE(6,'(I5,2X,F12.6)')ITERS,TOL -HALF)
Tempe, Arizona USA        OOOOOO \ENDDORETURN PARAMETER(ZERO=1.D0)*TENTH*DELTA

Re: gdb bug in Fortran langauge mode

[craig]

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

Re: gdb bug in Fortran langauge mode

[Jeffrey A Law]

  In message < Pine.SGI.3.96.990615233907.730A-100000@maxwell.la.asu.edu >you wri
te:
  > it on an RS6K, using the XLF compiler.  'objdump --syms badsym.o'
  > produces:
One could just as easily claim the XLF compiler is backwards.  

  > 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!
Not necessarily.

  > To resolve the problem, I ran gdb on a program compiled by IBM's XLF
  > compiler.  The array printing works fine and the 'whatis' was backwards. 
  > On an i86 with g77, the array printing doesn't work and 'whatis' does. 
  > 
  > The answer is that gcc/g77 is emitting the debug info for array elements
  > in the wrong order.  The reason the 'whatis' works on a g77 program is
  > because things are reversed twice. 
No, if you read the earlier messages, I think you'll find that folks here
think that that the order is correct.

jeff

Re: gdb bug in Fortran langauge mode

[Andy Vaught]

>Could whoever asserted that gdb works with "other" Fortran's please
>submit a complete example of this working, including the source code
>for a small Fortran program, the gdb session showing it working, and
>the assembler output of the "other" compiler when compiling that
>program, so we can see for ourselves just what "working" means in this
>case?


Start with the test program:

---------------
      program foo
      dimension array(3,4,5)

      array(1,1,1) = 1

      end
---------------

On i86, I compiled with: 'g77 -c -g badsym.f'

'objdump --stabs badsym.o' gives, in part:

57     LSYM   0      3      ffffff10 2373   array:(0,47)=ar(0,20);1;5;(0,48)=ar(0,20);1;4;(0,49)=ar(0,20);1;3;(0,32)

You can see that the last array element is first in the stab.  Now try
it on an RS6K, using the XLF compiler.  'objdump --syms badsym.o'
produces:


[ 15](sec -2)(fl 0x00)(ty   0)(scl 142) (nx 0) 0x00000000 foo:F-11
[ 16](sec  1)(fl 0x00)(ty   0)(scl 101) (nx 1) 0x00000014 .bf
AUX lnno 5 size 0x0 tagndx 0
[ 18](sec  3)(fl 0x00)(ty   0)(scl 143) (nx 0) 0x0000001e .bs
[ 19](sec -2)(fl 0x00)(ty   0)(scl 140) (nx 0) 0x00000000 :t5=ar0;1;3;ar0;1;4;ar0;1;5;-12
[ 20](sec -2)(fl 0x00)(ty   0)(scl 133) (nx 0) 0x00000000 array:V5
[ 21](sec  3)(fl 0x00)(ty   0)(scl 144) (nx 0) 0x00000000 .es
[ 22](sec  1)(fl 0x00)(ty   0)(scl 101) (nx 1) 0x00000030 .ef

Here we see that the first array element is emitted first, and so on.


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!

Looking at the gdb code that calculates the addresses of array
elements shows that they are computed in reverse order of how the
'whatis' commands prints them.  If we start from here, gdb is clearly
wrong at some point-- either the 'whatis' is backwards or address
calculation is backwards.

To resolve the problem, I ran gdb on a program compiled by IBM's XLF
compiler.  The array printing works fine and the 'whatis' was backwards. 
On an i86 with g77, the array printing doesn't work and 'whatis' does. 

The answer is that gcc/g77 is emitting the debug info for array elements
in the wrong order.  The reason the 'whatis' works on a g77 program is
because things are reversed twice. 

The debugging dump between the XLF and g77 programs show that the array
info is being emitted in opposite orders.  Since XLF and gdb work fine
together (and XLF also works with the bundled dbx debugger), it follows
that g77/gcc is the one emitting debug info in the wrong order, and that
gdb's 'whatis' command prints them in the wrong order. 


        Andy

-----------------                        XOLD(K,IC,I)=
Andy Vaught               ....        DO ITERS=1, 10  XOLD(K,IC,I)
andy@maxwell.la.asu.edu   |  |   /CALLMSOLVE(A,B,X,I,ITERS,TOL)+(RANNYU(0)
Arizona State University  ======|WRITE(6,'(I5,2X,F12.6)')ITERS,TOL -HALF)
Tempe, Arizona USA        OOOOOO \ENDDORETURN PARAMETER(ZERO=1.D0)*TENTH*DELTA