Re: gdb and g77

Re: gdb and g77

[Andrew Vaught]

>>  When g77 emits debug info for arrays, the dimensions are reversed.  If
>>your array is palindromic, ie "dimension a(10,20,10)", it will work OK,
>>but otherwise gdb will be looking at the wrong memory location for the
>>data.  I originally thought the problem was with gdb reversing the
>>dimensions, but after building gdb on an RS6K, it correctly read the
>>dimension info from the native RS6K compiler.  Ergo g77 is incorrect.


>Sounds reasonable, though the likely cause of the problem is the gcc
>back end.  The g77 front end (presumably) passes to the back end
>the proper info on the array, else there'd be *huge* problems, either
>in correctness or performance.  What is probably happening, then, is
>that the back end's debug modules (sdbout.c, dbxout.c, dwarfout.c,
>dwarf2out.c, etc.) aren't coping properly with multi-dimensional
>arrays.
>
>But I'm speaking on this without actually looking at any of the code,
>or -g output, etc.  I'm real busy this weekend, but will try to catch
>up on things like this shortly, though the fact that nobody else seems
>to have found the problem already suggests that it isn't an easy problem
>to spot!
>
>        tq vm, (burley)

  As far as I could tell, the problem is in ffecom_sym_transform(), right
before and possibly after that 130-line comment.  The procedure that
generates the code for array references appears to be in another section
of code, while ffecom_sym_transform() looks like it is packaging symbols
so that the back end can write the debug information. 

  I'm not surprised that no one has complained about this.  My experience
with people who do numerical computing is that they aren't that
sophisticated when it comes to debugging-- print statements are generally
what they do.  You can blow them away by attaching to a running process
with the debugger and printing out the values of variables...

(it looks like my return address is messed up.  It is andy@xena.eas.asu.edu)

    Andy

Re: gdb and g77

[craig]

>  As far as I could tell, the problem is in ffecom_sym_transform(), right
>before and possibly after that 130-line comment.  The procedure that
>generates the code for array references appears to be in another section
>of code, while ffecom_sym_transform() looks like it is packaging symbols
>so that the back end can write the debug information. 

Right, but if ffecom_sym_transform() is giving the back end the wrong
"shape" for multi-dimensional arrays, then surely Toon, at least, would
have noticed the resulting performance degradation!

Given a Fortran declaration like

  REAL A(5,6)

the ordering of elements, in memory, is *supposed* to be:

  A(1,1)
  A(2,1)
  A(3,1)
  A(4,1)
  A(5,1)
  A(1,2)
  A(2,2)
  ...

The back end doesn't care about "row" vs. "column" ordering, however.

In the back end, an array is *always* one-dimensional, but it may be
an array of a type that is, itself, another array.  So the ordering
is whatever it's given by the front end.

(Yes, it is a "C-ish" back end, but it does have a higher-level array
facility than C itself does, insofar that C cannot represent arrays
of arrays -- instead, it represents arrays of pointers to arrays, for
example.)

So the way g77 *should* be 'splaining the above declaration to the back
end is:

  A is a VAR_DECL (or PARM_DECL)
    of type ARRAY
        (6 elements in size)
      of type ARRAY
          (5 elements in size)
        of type REAL

Then, g77 tells the back end about a reference to A(2,1) as:

  ARRAY_REF (ARRAY_REF (A, 1), 2)

So g77 handles all the "column-ordering" stuff.  The back end never
sees it.

If g77 wasn't doing this right, then it'd either be *totally* broken
(which, I think it's safe to say after years of beta-testing, is
not the case!), or both the decl *and* the reference would be set
up the same "wrong" way.

But, if both were *wrong*, then the back end would be laying out
*memory* in the "wrong" way, even though typical array code would
still work.

This "wrong" layout would not only break EQUIVALENCE/COMMON overlapping
of multi-dimensional arrays with single-dimension ones, it'd also
result in much lower performance of code that was running through
arrays element by element using the proper column-ordering convention.

*My* guess, again, without looking at any code (except insofar as I *wrote*
the g77 code, so I'm pretty sure it's correct ;-) is that the problem
is in the back end code to handle writing debugging information.

That code doesn't expect to see "an array of an array" in C.  What
it might be doing is handling it incorrectly in general.  Or, something
I've seen people do, it might be handling it *correctly* in *general*,
then (wrongly) saying "hey, this is Fortran, let's reverse the ordering
of the subscripts, because Fortran is column-ordered".

I'd lean towards 39.999% likelihood of the former, 59.999% likelihood
of the latter, with the remaining being the likelihood of the bug
being somewhere else.

>  I'm not surprised that no one has complained about this.  My experience
>with people who do numerical computing is that they aren't that
>sophisticated when it comes to debugging-- print statements are generally
>what they do.  You can blow them away by attaching to a running process
>with the debugger and printing out the values of variables...

That's probably part of the equation: the other part being, I think
by now everybody knows g77's debuggability is pretty poor in certain
areas.

        tq vm, (burley)

Re: gdb and g77

[Jeffrey A Law]

  In message < 19990613232722.6682.qmail@deer >you write:
  >   A is a VAR_DECL (or PARM_DECL)
  >     of type ARRAY
  >         (6 elements in size)
  >       of type ARRAY
  >           (5 elements in size)
  >         of type REAL
  > 
  > Then, g77 tells the back end about a reference to A(2,1) as:
  > 
  >   ARRAY_REF (ARRAY_REF (A, 1), 2)
  > 
  > So g77 handles all the "column-ordering" stuff.  The back end never
  > sees it.
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.

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.

[ ... ]

  > That code doesn't expect to see "an array of an array" in C.  What
  > it might be doing is handling it incorrectly in general.  Or, something
  > I've seen people do, it might be handling it *correctly* in *general*,
  > then (wrongly) saying "hey, this is Fortran, let's reverse the ordering
  > of the subscripts, because Fortran is column-ordered".
I doubt it's the latter, at least in the compiler.  The code to emit
debug records is not supposed to really care about the language (and
thus shouldn't be reversing the subscripts).

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.

Depending on what we find, we either dive back into gcc itself or we start
looking at gdb.

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


jeff

Re: gdb and g77

[craig]

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

Re: gdb and g77

[David Edelsohn]

	Is this an issue where C specifies row-major arrays and Fortran
specifies column-major arrays?  The subscripts would appear to be reversed
if gdb did not set the language type correctly or handle the row-major
versus column-major specification.

David

Re: gdb and g77

[Richard Henderson]

On Mon, Jun 14, 1999 at 12:55:31AM -0600, Jeffrey A Law wrote:
>   1. gcc emits incorrect debug records.
> 
>   2. gdb interprets the debug records incorrectly.

3.  Gdb's fortran mode prints arrays in a confusing manner.  Columns
    are printed first, since they change more frequently.  But they 
    are printed in rows.

This was the conclusion I came to doing specfp95 debugging a 
few months ago, based on the fact that printing seemed skewed,
but expression evaluation and type info (as reported by ptype)
seemed fine.

I'm really very surprised to hear a report that gdb `works ok'
with the system compiler.

Another way to test debug info in gdb is to `set lang c' and 
see if things look more reasonable.


r~

Re: gdb and g77

[Jeffrey A Law]

  > 	Is this an issue where C specifies row-major arrays and Fortran
  > specifies column-major arrays?  The subscripts would appear to be reversed
  > if gdb did not set the language type correctly or handle the row-major
  > versus column-major specification.
I suspect the bug will turn out to be gdb.  But we need to verify that the
debug symbols being emitted from gcc look sane before we point a finger at
gdb  :-)

jeff

Re: gdb and g77

[Per Bothner]

Jeffrey A Law <law@cygnus.com> writes:

The way it *should* work IMNSHO:
* A f77 3*2 array should be represented internally (tree nodes etc)
the same as a C 2*3 array:  I.e. a 2-element array of 3-element arrays.
* The stabs should be the same for a f77 3*2 array as for a C 2*3 array.
* The internal Gdb representation of a f77 3*2 array should be the
asme as a C 2*3 array.
* When Gdb evaluates the f77 experession A(i,j) it should do the same
thing as when evaluating the C expression A[j][i].  This re-arranging
can be done by the expression parsing, or (by using a different
expression opcode) in the expression evaluator.  Because the parser
cannot distinguish a function call from an array indexing operation,
it does the latter, using the opcode OP_F77_UNDETERMINED_ARGLIST.

Rationale:  Logically, a f77 3*2 array is equivalent to a C 2*3 array
- it is just the order of indexes that are different.  The difference is
not one of types, but of expression syntax.  Hence the types should
be represented the same.

I worked on this some years ago, trying to clean up some code from
Motorola, but it has been a while, and may well have bit-rotten
- or been wrong in the first place.
-- 
	--Per Bothner
bothner@pacbell.net     http://home.pacbell.net/bothner/

Re: gdb and g77

[Joern Rennecke]

> (Yes, it is a "C-ish" back end, but it does have a higher-level array
> facility than C itself does, insofar that C cannot represent arrays
> of arrays -- instead, it represents arrays of pointers to arrays, for
> example.)

Huh?  C can represent arrays of arrays just fine.

Re: gdb and g77

[craig]

>I suspect the bug will turn out to be gdb.  But we need to verify that the
>debug symbols being emitted from gcc look sane before we point a finger at
>gdb  :-)

Well, it looks like there's general doubt on this list regarding the
statement that gdb works fine with "other" Fortran compilers.

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?

        tq vm, (burley)

Re: gdb and g77

[craig]

>> (Yes, it is a "C-ish" back end, but it does have a higher-level array
>> facility than C itself does, insofar that C cannot represent arrays
>> of arrays -- instead, it represents arrays of pointers to arrays, for
>> example.)
>
>Huh?  C can represent arrays of arrays just fine.

That's news to me.  Care to show how?  Note I said *represent* -- not
*implement* -- as any language that provides single-dimensional arrays
can be used to *implement* multi-dimensional arrays.

So, basically, what I'm asking is, what is the C notation that denotes
the equivalent to Fortran's

  REAL A(5,6)

(except that it's row-major, of course) *including* the fact that the
storage takes up 30 units of memory *and* the fact that the same array
declaration works just fine regardless of whether A is a local variable,
in common (external) storage, or a dummy argument (the last case being
especially notable)?

Reason I ask is, in the past, C programmers have occasionally taken
to comp.lang.fortran showing how "easy" it is to cons up a set of
preprocessor macros to make C *look* like it has multi-dimensional arrays
a la Fortran.  I'm sure they'd be quite surprised to learn that C
had them all along!

        tq vm, (burley)

Re: gdb and g77

[Joern Rennecke]

> >> (Yes, it is a "C-ish" back end, but it does have a higher-level array
> >> facility than C itself does, insofar that C cannot represent arrays
> >> of arrays -- instead, it represents arrays of pointers to arrays, for
> >> example.)
> >
> >Huh?  C can represent arrays of arrays just fine.
> 
> That's news to me.  Care to show how?  Note I said *represent* -- not
> *implement* -- as any language that provides single-dimensional arrays
> can be used to *implement* multi-dimensional arrays.
> 
> So, basically, what I'm asking is, what is the C notation that denotes
> the equivalent to Fortran's
> 
>   REAL A(5,6)
> 
> (except that it's row-major, of course) *including* the fact that the
> storage takes up 30 units of memory *and* the fact that the same array
> declaration works just fine regardless of whether A is a local variable,
> in common (external) storage, or a dummy argument (the last case being
> especially notable)?

You can't have an array argument - not even a one-dimensional one.
The array decays to a pointer to its first element; if you try to pass
an array of arrays of X, you get a pointer to the first array of X.

So, the array is left at the caller site, so to speak, while the callee
has to be content with being able to manipulate all elements of the
array via the passed pointer.

(You can of course wrap an array in a struct and pass that,
 but that's cheating ;-)

Re: gdb and g77

[Per Bothner]

craig@jcb-sc.com writes:

> So, basically, what I'm asking is, what is the C notation that denotes
> the equivalent to Fortran's
> 
>   REAL A(5,6)

float A[6][5];

As Joern says:  You can't have array arguments.

And as I said:  The two declarations should generate the *same*
(or at least equivalent) debug info.  If not, I doubt you will
get much help from the Gdb people until that is fixed.

Variable-length arrays (especially variable-length array arguments)
are a differnet complication.  There is no real support for that
in stabs or Gdb, though the Motorola did implement some gross
hacks to handle some of the cases.  To handle variable-length
arrays, my incination would be to give up on stabs, and try to
design a clean solution using dwarf2.
-- 
	--Per Bothner
bothner@pacbell.net     http://home.pacbell.net/bothner/

gdb bug in Fortran language mode [was Re: gdb and g77]

[craig]

The summary: I believe gdb is the culprit, specifically, its Fortran
language mode doesn't handle multi-dimension arrays (for stabs debugging
anyway) correctly.

>>Huh?  C can represent arrays of arrays just fine.
>
>That's news to me.  Care to show how?  Note I said *represent* -- not

Nevermind.  I just realized, the extent of *support* for this
representation of C is not, per se, relevant to this issue.

All that matters is whether *gcc* (the front end) generates, for
the back end's amusement, notations such as ARRAY_REF(ARRAY_REF(...),N)
and VAR_DECL of type array of type array of type ....

Indeed, I just verified it does.

What I can't see are any substantive differences between the assembler
(especially stabs) code g77 and gcc produce for:

--------
#include <stdio.h>

int
main()
{
  float a[6][5];

  a[2][3] = 5;
  return 0;
}
--------

and

--------
      REAL A(0:4,0:5)
      A(3,2) = 5
      END
--------

other than some stabs-related stuff I don't quite understand.  (-ggdb
didn't help, because I can't read the bytecodes offhand.)

Based on playing with this a bit, it looks like it's just a case of
gdb not working right.  gdb's Fortran mode prints the correct info
for `whatis', and seems to handle `p a' just fine, but anything beyond
the `p a(N,0)', such as `p a(0,1)', it doesn't seem to properly cope with.

Enclosed is info showing that gdb seems to basically be
confused about the extent of one of the dimensions (off by one?).

        tq vm, (burley)


Fortran source:
--------
      REAL A(0:4,0:5)
      DO I=0,5
         DO J=0,4
            A(J,I) = J * 100 + I
         END DO
      END DO
      PAUSE
      END
--------

gdb session:
--------
Current directory is ~/gnu/play/
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) r
Starting program: /home3/craig/gnu/play/a.out 

Program exited normally.
(gdb) file a.out
Load new symbol table from "a.out"? (y or n) y
Reading symbols from a.out...done.
(gdb) r
Starting program: /home3/craig/gnu/play/a.out 
PAUSE  statement executed
To resume execution, type go.  Other input will terminate the job.

Program received signal SIGINT, Interrupt.
0x400926f4 in read () from /lib/libc.so.6
(gdb) up
#1  0x400c06cc in __DTOR_END__ () from /lib/libc.so.6
(gdb) 
#2  0x4006456c in _IO_file_underflow (fp=0x804be08) at fileops.c:303
303	fileops.c: No such file or directory.
(gdb) 
#3  0x400652ed in _IO_default_uflow (fp=0x804be08) at genops.c:313
313	genops.c: No such file or directory.
(gdb) 
#4  0x400651f8 in __uflow (fp=0x804be08) at genops.c:273
273	in genops.c
(gdb) 
#5  0x400634cc in _IO_getc (fp=0x804be08) at getc.c:38
38	getc.c: No such file or directory.
(gdb) 
#6  0x8048dcd in s_1paus (fin=0x804be08)
    at ../../../../g77-e/libf2c/libF77/s_paus.c:40
(gdb) 
#7  0x8048e92 in s_paus (s=0x804a4c0 "STOP ", n=0)
    at ../../../../g77-e/libf2c/libF77/s_paus.c:61
(gdb) 
#8  0x8048cbf in MAIN__ () at ar1.f:7
Current language:  auto; currently fortran
(gdb) p a
$1 = (( 0, 100, 200, 300, 400) ( 1, 101, 201, 301, 401) ( 2, 102, 202, 302, 402) ( 3, 103, 203, 303, 403) ( 4, 104, 204, 304, 404) ( 5, 105, 205, 305, 405) )
(gdb) p a(0,0)
$2 = 0
(gdb) p a(1,0)
$3 = 100
(gdb) p a(2,0)
$4 = 200
(gdb) p a(3,0)
$5 = 300
(gdb) p a(4,0)
$6 = 400
(gdb) p a(5,0)
$7 = 1
(gdb) p a(0,1)
$8 = 101                             <== all `p' output from here down WRONG!
(gdb) p a(1,1)
$9 = 201
(gdb) p a(2,1)
$10 = 301
(gdb) p a(3,1)
$11 = 401
(gdb) p a(4,1)
$12 = 2
(gdb) p a(0,2)
$13 = 202
(gdb) p a(1,2)
$14 = 302
(gdb) p a(2,2)
$15 = 402
(gdb) whatis a
type = real*4 (0:4,0:5)
(gdb) quit
The program is running.  Exit anyway? (y or n) y

Debugger finished
--------

-S output from Fortran source:
--------
	.file	"ar1.f"
	.version	"01.01"
.stabs "/home3/craig/gnu/play/",100,0,0,.Ltext0
.stabs "ar1.f",100,0,0,.Ltext0
.text
.Ltext0:
	.stabs	"gcc2_compiled.", 0x3c, 0, 0, 0
.stabs "int:t(0,1)=r(0,1);0020000000000;0017777777777;",128,0,0,0
.stabs "char:t(0,2)=r(0,2);0;255;",128,0,0,0
.stabs "long int:t(0,3)=r(0,1);0020000000000;0017777777777;",128,0,0,0
.stabs "unsigned int:t(0,4)=r(0,1);0000000000000;0037777777777;",128,0,0,0
.stabs "long unsigned int:t(0,5)=r(0,1);0000000000000;0037777777777;",128,0,0,0
.stabs "long long int:t(0,6)=r(0,1);01000000000000000000000;0777777777777777777777;",128,0,0,0
.stabs "long long unsigned int:t(0,7)=r(0,1);0000000000000;01777777777777777777777;",128,0,0,0
.stabs "short int:t(0,8)=r(0,8);-32768;32767;",128,0,0,0
.stabs "short unsigned int:t(0,9)=r(0,9);0;65535;",128,0,0,0
.stabs "signed char:t(0,10)=r(0,10);-128;127;",128,0,0,0
.stabs "unsigned char:t(0,11)=r(0,11);0;255;",128,0,0,0
.stabs "float:t(0,12)=r(0,1);4;0;",128,0,0,0
.stabs "double:t(0,13)=r(0,1);8;0;",128,0,0,0
.stabs "long double:t(0,14)=r(0,1);12;0;",128,0,0,0
.stabs "complex int:t(0,15)=s8real:(0,1),0,32;imag:(0,1),32,32;;",128,0,0,0
.stabs "complex float:t(0,16)=r(0,16);4;0;",128,0,0,0
.stabs "complex double:t(0,17)=r(0,17);8;0;",128,0,0,0
.stabs "complex long double:t(0,18)=r(0,18);12;0;",128,0,0,0
.stabs "void:t(0,19)=(0,19)",128,0,0,0
.stabs "integer:t(0,20)=r(0,1);0020000000000;0017777777777;",128,0,0,0
.stabs "unsigned:t(0,21)=r(0,1);0000000000000;0037777777777;",128,0,0,0
.stabs "byte:t(0,22)=r(0,22);-128;127;",128,0,0,0
.stabs "unsigned byte:t(0,23)=r(0,23);0;255;",128,0,0,0
.stabs "word:t(0,24)=r(0,24);-32768;32767;",128,0,0,0
.stabs "unsigned word:t(0,25)=r(0,25);0;65535;",128,0,0,0
.stabs "integer4:t(0,26)=r(0,1);01000000000000000000000;0777777777777777777777;",128,0,0,0
.stabs "unsigned4:t(0,27)=r(0,1);0000000000000;01777777777777777777777;",128,0,0,0
.stabs "logical:t(0,28)=r(0,1);0020000000000;0017777777777;",128,0,0,0
.stabs "logical2:t(0,29)=r(0,29);-128;127;",128,0,0,0
.stabs "logical3:t(0,30)=r(0,30);-32768;32767;",128,0,0,0
.stabs "logical4:t(0,31)=r(0,1);01000000000000000000000;0777777777777777777777;",128,0,0,0
.stabs "real:t(0,32)=r(0,1);4;0;",128,0,0,0
.stabs "double precision:t(0,33)=r(0,1);8;0;",128,0,0,0
.stabs "complex:t(0,34)=r(0,34);4;0;",128,0,0,0
.stabs "double complex:t(0,35)=r(0,35);8;0;",128,0,0,0
.stabs "__g77_f2c_integer:t(0,36)=r(0,1);0020000000000;0017777777777;",128,0,0,0
.stabs "__g77_f2c_address:t(0,37)=*(0,10)",128,0,0,0
.stabs "__g77_f2c_real:t(0,38)=r(0,1);4;0;",128,0,0,0
.stabs "__g77_f2c_doublereal:t(0,39)=r(0,1);8;0;",128,0,0,0
.stabs "__g77_f2c_complex:t(0,40)=r(0,40);4;0;",128,0,0,0
.stabs "__g77_f2c_doublecomplex:t(0,41)=r(0,41);8;0;",128,0,0,0
.stabs "__g77_f2c_longint:t(0,42)=r(0,1);01000000000000000000000;0777777777777777777777;",128,0,0,0
.stabs "__g77_f2c_logical:t(0,43)=r(0,1);0020000000000;0017777777777;",128,0,0,0
.stabs "__g77_f2c_flag:t(0,44)=r(0,1);0020000000000;0017777777777;",128,0,0,0
.stabs "__g77_f2c_ftnlen:t(0,45)=r(0,1);0020000000000;0017777777777;",128,0,0,0
.stabs "__g77_f2c_ftnint:t(0,46)=r(0,1);0020000000000;0017777777777;",128,0,0,0
.section	.rodata
.LC0:
.text
	.align 4
.stabs "MAIN__:F(0,19)",36,0,1,MAIN__
.globl MAIN__
	.type	 MAIN__,@function
MAIN__:
.stabn 68,0,1,.LM1-MAIN__
.LM1:
	pushl %ebp
	movl %esp,%ebp
	subl $164,%esp
	pushl %ebx
.stabn 68,0,1,.LM2-MAIN__
.LM2:
.LBB2:
.stabn 68,0,2,.LM3-MAIN__
.LM3:
.LBB3:
	movl $6,-140(%ebp)
	movl $0,-132(%ebp)
	.p2align 4,,7
.L3:
	decl -140(%ebp)
	cmpl $0,-140(%ebp)
	jge .L6
	jmp .L4
	.p2align 4,,7
.L6:
.stabn 68,0,3,.LM4-MAIN__
.LM4:
.LBB4:
	movl $5,-144(%ebp)
	movl $0,-136(%ebp)
	.p2align 4,,7
.L7:
	decl -144(%ebp)
	cmpl $0,-144(%ebp)
	jge .L10
	jmp .L5
	.p2align 4,,7
.L10:
.stabn 68,0,4,.LM5-MAIN__
.LM5:
	movl -136(%ebp),%eax
	movl %eax,%edx
	leal 0(,%edx,4),%eax
	movl -132(%ebp),%ecx
	movl %ecx,%edx
	sall $2,%edx
	addl %ecx,%edx
	leal 0(,%edx,4),%ecx
	addl %ecx,%eax
	leal -128(%ebp),%edx
	movl -136(%ebp),%ebx
	movl %ebx,%ecx
	sall $2,%ecx
	addl %ebx,%ecx
	leal 0(,%ecx,4),%ebx
	addl %ebx,%ecx
	leal 0(,%ecx,4),%ebx
	movl %ebx,%ecx
	addl -132(%ebp),%ecx
	movl %ecx,-148(%ebp)
	fildl -148(%ebp)
	fstps (%eax,%edx)
.stabn 68,0,5,.LM6-MAIN__
.LM6:
.L9:
	incl -136(%ebp)
	jmp .L7
	.p2align 4,,7
.L8:
.LBE4:
.stabn 68,0,6,.LM7-MAIN__
.LM7:
.L5:
	incl -132(%ebp)
	jmp .L3
	.p2align 4,,7
.L4:
.LBE3:
.stabn 68,0,7,.LM8-MAIN__
.LM8:
	addl $-8,%esp
	pushl $0
	pushl $.LC0
	call s_paus
	addl $16,%esp
.stabn 68,0,8,.LM9-MAIN__
.LM9:
	addl $-8,%esp
	pushl $0
	pushl $.LC0
	call s_stop
	addl $16,%esp
.LBE2:
.stabn 68,0,8,.LM10-MAIN__
.LM10:
	.p2align 4,,7
.L2:
	movl -168(%ebp),%ebx
	movl %ebp,%esp
	popl %ebp
	ret
.Lfe1:
	.size	 MAIN__,.Lfe1-MAIN__
.stabs "a:(0,47)=ar(0,20);0;5;(0,48)=ar(0,20);0;4;(0,32)",128,0,1,-128
.stabs "i:(0,20)",128,0,2,-132
.stabs "j:(0,20)",128,0,3,-136
.stabn 192,0,0,.LBB2-MAIN__
.stabs "__g77_do_0:(0,20)",128,0,2,-140
.stabn 192,0,0,.LBB3-MAIN__
.stabs "__g77_do_1:(0,20)",128,0,3,-144
.stabn 192,0,0,.LBB4-MAIN__
.stabn 224,0,0,.LBE4-MAIN__
.stabn 224,0,0,.LBE3-MAIN__
.stabn 224,0,0,.LBE2-MAIN__
.Lscope0:
.stabs "",36,0,0,.Lscope0-MAIN__
	.text
	.stabs "",100,0,0,Letext
Letext:
	.ident	"GCC: (GNU) gcc-2.95 19990524 (prerelease)"
--------

a bit more of a (new) gdb session showing that gdb handles the same
code fine in C language mode:
--------
(gdb) set lang c
(gdb) p a
$1 = {{0, 100, 200, 300, 400}, {1, 101, 201, 301, 401}, {2, 102, 202, 302, 
    402}, {3, 103, 203, 303, 403}, {4, 104, 204, 304, 404}, {5, 105, 205, 305, 
    405}}
(gdb) p a[0][0]
$2 = 0
(gdb) p a[0][1]
$3 = 100
(gdb) p a[0][4]
$4 = 400
(gdb) p a[1][0]
$5 = 1
(gdb) p a[1][1]
$6 = 101
(gdb) whatis a
type = real [6][5]
(gdb) 
--------

Re: gdb bug in Fortran language mode [was Re: gdb and g77]

[Stan Shebs]

   From: craig@jcb-sc.com
   Date: 15 Jun 1999 00:06:28 -0000

   The summary: I believe gdb is the culprit, specifically, its Fortran
   language mode doesn't handle multi-dimension arrays (for stabs debugging
   anyway) correctly.

OK, if you're satisfied that GCC's output is correct, then we can take
over on the GDB side.  GDB's Fortran support hasn't been touched in a
while, and the original contribution was only tested with Motorola or
AIX compilers or something like that.

								Stan

Re: gdb bug in Fortran language mode [was Re: gdb and g77]

[Jeffrey A Law]

  In message < 199906150016.RAA06796@andros.cygnus.com >you write:
  > OK, if you're satisfied that GCC's output is correct, then we can take
  > over on the GDB side.  GDB's Fortran support hasn't been touched in a
  > while, and the original contribution was only tested with Motorola or
  > AIX compilers or something like that.
It's looking more and more like a gdb issue.  I'm going to grope around and
see if I can come up with a copy of HP Fortran for some minimal testing.

jeff

Re: gdb bug in Fortran language mode [was Re: gdb and g77]

[YABUKI Youichi]

>   In message < 199906150016.RAA06796@andros.cygnus.com >you write:
>   > OK, if you're satisfied that GCC's output is correct, then we can take
>   > over on the GDB side.  GDB's Fortran support hasn't been touched in a
>   > while, and the original contribution was only tested with Motorola or
>   > AIX compilers or something like that.
> It's looking more and more like a gdb issue.  I'm going to grope around and
> see if I can come up with a copy of HP Fortran for some minimal testing.

We, SRA's Wingnut project have added the support for HITACHI's SR2201
to gdb-4.17. Which includes HITACHI's FORTRAN77 compiler support.
Although not tested for output from g77, it may help you.

This patch is available at

ftp://ftp.sra.co.jp/pub/gnu/wingnut/hiuxmpp/gdb-4.17/gdb-4.17.hmpp.diff-980729 .

Here is the README file:
===========================================================================
his directory contains the patch to gdb-4.17 which support
        HITACHI SR2201 - PA-RISC based MPP machine,
        HI-UX/MPP base OSF/1.

This patch support HITACHI's FORTRAN77 compiler support as well as
basic C(and C++) supports.
This FORTRAN77 support includes
some modifications to GDB's FORTRAN77 frontend and
some enhancement to HP's DEBUG information(HI-UX/MPP use it) support.
This patch includes also about 1000 FORTRAN77 test cases merged to
gdb-4.17's testsuite.

Files:
README                          this file
gdb-4.17.hmpp.diff-980728       patch to gdb-4.17
===========================================================================
YABKI Youich, Wingnut project at SRA.

Re: gdb bug in Fortran language mode [was Re: gdb and g77]

[Jeffrey A Law]

  In message < 19990615000628.10897.qmail@deer >you write:
  > The summary: I believe gdb is the culprit, specifically, its Fortran
  > language mode doesn't handle multi-dimension arrays (for stabs debugging
  > anyway) correctly.
That is my opinion too.

For the Fortran example we get following stab

.stabs "a:(0,47)=ar(0,20);0;5;(0,48)=ar(0,20);0;4;(0,32)",128,0,1,-128

  > --------
  >       REAL A(0:4,0:5)
  >       A(3,2) = 5
  >       END
  > --------


It defines two new types (47 & 48).

Type 47 is an array.  The index type is 20 (integer) with a range 0..5
inclusive. The elements in the array are of type 48.

Type for is an array.  The index type is 20 (integer) with a range of 0..4
inclusive.  The elements in this arary are of type 32 (real).

The fact that when you print the array as a whole and it looks OK leads
me to believe that gdb's reading in the debug record and interpreting it
correctly.  When you try to print individual elements, things go wacko,
makes me wonder about the expression parser in gdb.

Re: gdb and g77

[Jeffrey A Law]

  In message < m2yahmlidn.fsf@magnus.cygnus.com >you write:
  > Jeffrey A Law <law@cygnus.com> writes:
  > 
  > The way it *should* work IMNSHO:
  > * A f77 3*2 array should be represented internally (tree nodes etc)
  > the same as a C 2*3 array:  I.e. a 2-element array of 3-element arrays.
It is.

  > * The stabs should be the same for a f77 3*2 array as for a C 2*3 array.
They are (verified by Craig & myself).

  > * The internal Gdb representation of a f77 3*2 array should be the
  > asme as a C 2*3 array.
  > * When Gdb evaluates the f77 experession A(i,j) it should do the same
  > thing as when evaluating the C expression A[j][i].  This re-arranging
  > can be done by the expression parsing, or (by using a different
  > expression opcode) in the expression evaluator.  Because the parser
  > cannot distinguish a function call from an array indexing operation,
  > it does the latter, using the opcode OP_F77_UNDETERMINED_ARGLIST.
These are where we'll start concentrating our efforts now that we're
fairly sure the stabs are reasonable.

jeff

Re: gdb bug in Fortran language mode [was Re: gdb and g77]

[Stan Shebs]

   Date: Tue, 15 Jun 1999 13:42:59 +0900
   From: YABUKI Youichi <yabuki@sra.co.jp>

   We, SRA's Wingnut project have added the support for HITACHI's SR2201
   to gdb-4.17. Which includes HITACHI's FORTRAN77 compiler support.
   Although not tested for output from g77, it may help you.

   This patch is available at

   ftp://ftp.sra.co.jp/pub/gnu/wingnut/hiuxmpp/gdb-4.17/gdb-4.17.hmpp.diff-980729 .

Have you sent a copyright assignment form to the FSF for these
changes?  We will need that in before we can incorporate any of these
(which so far look pretty interesting...).  If you haven't assigned
copyright yet, you can find instructions at
http://sourceware.cygnus.com/gdb/contribute.html .  If anything is
unclear, feel free to send me mail.

							Stan Shebs
							Cygnus Solutions
							shebs@cygnus.com

Re: gdb and g77

[Andrew Vaught]

>>  When g77 emits debug info for arrays, the dimensions are reversed.  If
>>your array is palindromic, ie "dimension a(10,20,10)", it will work OK,
>>but otherwise gdb will be looking at the wrong memory location for the
>>data.  I originally thought the problem was with gdb reversing the
>>dimensions, but after building gdb on an RS6K, it correctly read the
>>dimension info from the native RS6K compiler.  Ergo g77 is incorrect.


>Sounds reasonable, though the likely cause of the problem is the gcc
>back end.  The g77 front end (presumably) passes to the back end
>the proper info on the array, else there'd be *huge* problems, either
>in correctness or performance.  What is probably happening, then, is
>that the back end's debug modules (sdbout.c, dbxout.c, dwarfout.c,
>dwarf2out.c, etc.) aren't coping properly with multi-dimensional
>arrays.
>
>But I'm speaking on this without actually looking at any of the code,
>or -g output, etc.  I'm real busy this weekend, but will try to catch
>up on things like this shortly, though the fact that nobody else seems
>to have found the problem already suggests that it isn't an easy problem
>to spot!
>
>        tq vm, (burley)

  As far as I could tell, the problem is in ffecom_sym_transform(), right
before and possibly after that 130-line comment.  The procedure that
generates the code for array references appears to be in another section
of code, while ffecom_sym_transform() looks like it is packaging symbols
so that the back end can write the debug information. 

  I'm not surprised that no one has complained about this.  My experience
with people who do numerical computing is that they aren't that
sophisticated when it comes to debugging-- print statements are generally
what they do.  You can blow them away by attaching to a running process
with the debugger and printing out the values of variables...

(it looks like my return address is messed up.  It is andy@xena.eas.asu.edu)

    Andy

Re: gdb and g77

[Jeffrey A Law]

  > 	Is this an issue where C specifies row-major arrays and Fortran
  > specifies column-major arrays?  The subscripts would appear to be reversed
  > if gdb did not set the language type correctly or handle the row-major
  > versus column-major specification.
I suspect the bug will turn out to be gdb.  But we need to verify that the
debug symbols being emitted from gcc look sane before we point a finger at
gdb  :-)

jeff

Re: gdb and g77

[craig]

>I suspect the bug will turn out to be gdb.  But we need to verify that the
>debug symbols being emitted from gcc look sane before we point a finger at
>gdb  :-)

Well, it looks like there's general doubt on this list regarding the
statement that gdb works fine with "other" Fortran compilers.

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?

        tq vm, (burley)

Re: gdb and g77

[Joern Rennecke]

> (Yes, it is a "C-ish" back end, but it does have a higher-level array
> facility than C itself does, insofar that C cannot represent arrays
> of arrays -- instead, it represents arrays of pointers to arrays, for
> example.)

Huh?  C can represent arrays of arrays just fine.

Re: gdb bug in Fortran language mode [was Re: gdb and g77]

[YABUKI Youichi]

>   In message < 199906150016.RAA06796@andros.cygnus.com >you write:
>   > OK, if you're satisfied that GCC's output is correct, then we can take
>   > over on the GDB side.  GDB's Fortran support hasn't been touched in a
>   > while, and the original contribution was only tested with Motorola or
>   > AIX compilers or something like that.
> It's looking more and more like a gdb issue.  I'm going to grope around and
> see if I can come up with a copy of HP Fortran for some minimal testing.

We, SRA's Wingnut project have added the support for HITACHI's SR2201
to gdb-4.17. Which includes HITACHI's FORTRAN77 compiler support.
Although not tested for output from g77, it may help you.

This patch is available at

ftp://ftp.sra.co.jp/pub/gnu/wingnut/hiuxmpp/gdb-4.17/gdb-4.17.hmpp.diff-980729 .

Here is the README file:
===========================================================================
his directory contains the patch to gdb-4.17 which support
        HITACHI SR2201 - PA-RISC based MPP machine,
        HI-UX/MPP base OSF/1.

This patch support HITACHI's FORTRAN77 compiler support as well as
basic C(and C++) supports.
This FORTRAN77 support includes
some modifications to GDB's FORTRAN77 frontend and
some enhancement to HP's DEBUG information(HI-UX/MPP use it) support.
This patch includes also about 1000 FORTRAN77 test cases merged to
gdb-4.17's testsuite.

Files:
README                          this file
gdb-4.17.hmpp.diff-980728       patch to gdb-4.17
===========================================================================
YABKI Youich, Wingnut project at SRA.

Re: gdb bug in Fortran language mode [was Re: gdb and g77]

[Stan Shebs]

   Date: Tue, 15 Jun 1999 13:42:59 +0900
   From: YABUKI Youichi <yabuki@sra.co.jp>

   We, SRA's Wingnut project have added the support for HITACHI's SR2201
   to gdb-4.17. Which includes HITACHI's FORTRAN77 compiler support.
   Although not tested for output from g77, it may help you.

   This patch is available at

   ftp://ftp.sra.co.jp/pub/gnu/wingnut/hiuxmpp/gdb-4.17/gdb-4.17.hmpp.diff-980729 .

Have you sent a copyright assignment form to the FSF for these
changes?  We will need that in before we can incorporate any of these
(which so far look pretty interesting...).  If you haven't assigned
copyright yet, you can find instructions at
http://sourceware.cygnus.com/gdb/contribute.html .  If anything is
unclear, feel free to send me mail.

							Stan Shebs
							Cygnus Solutions
							shebs@cygnus.com

Re: gdb and g77

[Per Bothner]

craig@jcb-sc.com writes:

> So, basically, what I'm asking is, what is the C notation that denotes
> the equivalent to Fortran's
> 
>   REAL A(5,6)

float A[6][5];

As Joern says:  You can't have array arguments.

And as I said:  The two declarations should generate the *same*
(or at least equivalent) debug info.  If not, I doubt you will
get much help from the Gdb people until that is fixed.

Variable-length arrays (especially variable-length array arguments)
are a differnet complication.  There is no real support for that
in stabs or Gdb, though the Motorola did implement some gross
hacks to handle some of the cases.  To handle variable-length
arrays, my incination would be to give up on stabs, and try to
design a clean solution using dwarf2.
-- 
	--Per Bothner
bothner@pacbell.net     http://home.pacbell.net/bothner/

Re: gdb and g77

[craig]

>  As far as I could tell, the problem is in ffecom_sym_transform(), right
>before and possibly after that 130-line comment.  The procedure that
>generates the code for array references appears to be in another section
>of code, while ffecom_sym_transform() looks like it is packaging symbols
>so that the back end can write the debug information. 

Right, but if ffecom_sym_transform() is giving the back end the wrong
"shape" for multi-dimensional arrays, then surely Toon, at least, would
have noticed the resulting performance degradation!

Given a Fortran declaration like

  REAL A(5,6)

the ordering of elements, in memory, is *supposed* to be:

  A(1,1)
  A(2,1)
  A(3,1)
  A(4,1)
  A(5,1)
  A(1,2)
  A(2,2)
  ...

The back end doesn't care about "row" vs. "column" ordering, however.

In the back end, an array is *always* one-dimensional, but it may be
an array of a type that is, itself, another array.  So the ordering
is whatever it's given by the front end.

(Yes, it is a "C-ish" back end, but it does have a higher-level array
facility than C itself does, insofar that C cannot represent arrays
of arrays -- instead, it represents arrays of pointers to arrays, for
example.)

So the way g77 *should* be 'splaining the above declaration to the back
end is:

  A is a VAR_DECL (or PARM_DECL)
    of type ARRAY
        (6 elements in size)
      of type ARRAY
          (5 elements in size)
        of type REAL

Then, g77 tells the back end about a reference to A(2,1) as:

  ARRAY_REF (ARRAY_REF (A, 1), 2)

So g77 handles all the "column-ordering" stuff.  The back end never
sees it.

If g77 wasn't doing this right, then it'd either be *totally* broken
(which, I think it's safe to say after years of beta-testing, is
not the case!), or both the decl *and* the reference would be set
up the same "wrong" way.

But, if both were *wrong*, then the back end would be laying out
*memory* in the "wrong" way, even though typical array code would
still work.

This "wrong" layout would not only break EQUIVALENCE/COMMON overlapping
of multi-dimensional arrays with single-dimension ones, it'd also
result in much lower performance of code that was running through
arrays element by element using the proper column-ordering convention.

*My* guess, again, without looking at any code (except insofar as I *wrote*
the g77 code, so I'm pretty sure it's correct ;-) is that the problem
is in the back end code to handle writing debugging information.

That code doesn't expect to see "an array of an array" in C.  What
it might be doing is handling it incorrectly in general.  Or, something
I've seen people do, it might be handling it *correctly* in *general*,
then (wrongly) saying "hey, this is Fortran, let's reverse the ordering
of the subscripts, because Fortran is column-ordered".

I'd lean towards 39.999% likelihood of the former, 59.999% likelihood
of the latter, with the remaining being the likelihood of the bug
being somewhere else.

>  I'm not surprised that no one has complained about this.  My experience
>with people who do numerical computing is that they aren't that
>sophisticated when it comes to debugging-- print statements are generally
>what they do.  You can blow them away by attaching to a running process
>with the debugger and printing out the values of variables...

That's probably part of the equation: the other part being, I think
by now everybody knows g77's debuggability is pretty poor in certain
areas.

        tq vm, (burley)

Re: gdb and g77

[Joern Rennecke]

> >> (Yes, it is a "C-ish" back end, but it does have a higher-level array
> >> facility than C itself does, insofar that C cannot represent arrays
> >> of arrays -- instead, it represents arrays of pointers to arrays, for
> >> example.)
> >
> >Huh?  C can represent arrays of arrays just fine.
> 
> That's news to me.  Care to show how?  Note I said *represent* -- not
> *implement* -- as any language that provides single-dimensional arrays
> can be used to *implement* multi-dimensional arrays.
> 
> So, basically, what I'm asking is, what is the C notation that denotes
> the equivalent to Fortran's
> 
>   REAL A(5,6)
> 
> (except that it's row-major, of course) *including* the fact that the
> storage takes up 30 units of memory *and* the fact that the same array
> declaration works just fine regardless of whether A is a local variable,
> in common (external) storage, or a dummy argument (the last case being
> especially notable)?

You can't have an array argument - not even a one-dimensional one.
The array decays to a pointer to its first element; if you try to pass
an array of arrays of X, you get a pointer to the first array of X.

So, the array is left at the caller site, so to speak, while the callee
has to be content with being able to manipulate all elements of the
array via the passed pointer.

(You can of course wrap an array in a struct and pass that,
 but that's cheating ;-)

Re: gdb bug in Fortran language mode [was Re: gdb and g77]

[Jeffrey A Law]

  In message < 19990615000628.10897.qmail@deer >you write:
  > The summary: I believe gdb is the culprit, specifically, its Fortran
  > language mode doesn't handle multi-dimension arrays (for stabs debugging
  > anyway) correctly.
That is my opinion too.

For the Fortran example we get following stab

.stabs "a:(0,47)=ar(0,20);0;5;(0,48)=ar(0,20);0;4;(0,32)",128,0,1,-128

  > --------
  >       REAL A(0:4,0:5)
  >       A(3,2) = 5
  >       END
  > --------


It defines two new types (47 & 48).

Type 47 is an array.  The index type is 20 (integer) with a range 0..5
inclusive. The elements in the array are of type 48.

Type for is an array.  The index type is 20 (integer) with a range of 0..4
inclusive.  The elements in this arary are of type 32 (real).

The fact that when you print the array as a whole and it looks OK leads
me to believe that gdb's reading in the debug record and interpreting it
correctly.  When you try to print individual elements, things go wacko,
makes me wonder about the expression parser in gdb.

Re: gdb and g77

[Jeffrey A Law]

  In message < 19990613232722.6682.qmail@deer >you write:
  >   A is a VAR_DECL (or PARM_DECL)
  >     of type ARRAY
  >         (6 elements in size)
  >       of type ARRAY
  >           (5 elements in size)
  >         of type REAL
  > 
  > Then, g77 tells the back end about a reference to A(2,1) as:
  > 
  >   ARRAY_REF (ARRAY_REF (A, 1), 2)
  > 
  > So g77 handles all the "column-ordering" stuff.  The back end never
  > sees it.
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.

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.

[ ... ]

  > That code doesn't expect to see "an array of an array" in C.  What
  > it might be doing is handling it incorrectly in general.  Or, something
  > I've seen people do, it might be handling it *correctly* in *general*,
  > then (wrongly) saying "hey, this is Fortran, let's reverse the ordering
  > of the subscripts, because Fortran is column-ordered".
I doubt it's the latter, at least in the compiler.  The code to emit
debug records is not supposed to really care about the language (and
thus shouldn't be reversing the subscripts).

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.

Depending on what we find, we either dive back into gcc itself or we start
looking at gdb.

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


jeff

gdb bug in Fortran language mode [was Re: gdb and g77]

[craig]

The summary: I believe gdb is the culprit, specifically, its Fortran
language mode doesn't handle multi-dimension arrays (for stabs debugging
anyway) correctly.

>>Huh?  C can represent arrays of arrays just fine.
>
>That's news to me.  Care to show how?  Note I said *represent* -- not

Nevermind.  I just realized, the extent of *support* for this
representation of C is not, per se, relevant to this issue.

All that matters is whether *gcc* (the front end) generates, for
the back end's amusement, notations such as ARRAY_REF(ARRAY_REF(...),N)
and VAR_DECL of type array of type array of type ....

Indeed, I just verified it does.

What I can't see are any substantive differences between the assembler
(especially stabs) code g77 and gcc produce for:

--------
#include <stdio.h>

int
main()
{
  float a[6][5];

  a[2][3] = 5;
  return 0;
}
--------

and

--------
      REAL A(0:4,0:5)
      A(3,2) = 5
      END
--------

other than some stabs-related stuff I don't quite understand.  (-ggdb
didn't help, because I can't read the bytecodes offhand.)

Based on playing with this a bit, it looks like it's just a case of
gdb not working right.  gdb's Fortran mode prints the correct info
for `whatis', and seems to handle `p a' just fine, but anything beyond
the `p a(N,0)', such as `p a(0,1)', it doesn't seem to properly cope with.

Enclosed is info showing that gdb seems to basically be
confused about the extent of one of the dimensions (off by one?).

        tq vm, (burley)


Fortran source:
--------
      REAL A(0:4,0:5)
      DO I=0,5
         DO J=0,4
            A(J,I) = J * 100 + I
         END DO
      END DO
      PAUSE
      END
--------

gdb session:
--------
Current directory is ~/gnu/play/
GNU gdb 4.18
Copyright 1998 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) r
Starting program: /home3/craig/gnu/play/a.out 

Program exited normally.
(gdb) file a.out
Load new symbol table from "a.out"? (y or n) y
Reading symbols from a.out...done.
(gdb) r
Starting program: /home3/craig/gnu/play/a.out 
PAUSE  statement executed
To resume execution, type go.  Other input will terminate the job.

Program received signal SIGINT, Interrupt.
0x400926f4 in read () from /lib/libc.so.6
(gdb) up
#1  0x400c06cc in __DTOR_END__ () from /lib/libc.so.6
(gdb) 
#2  0x4006456c in _IO_file_underflow (fp=0x804be08) at fileops.c:303
303	fileops.c: No such file or directory.
(gdb) 
#3  0x400652ed in _IO_default_uflow (fp=0x804be08) at genops.c:313
313	genops.c: No such file or directory.
(gdb) 
#4  0x400651f8 in __uflow (fp=0x804be08) at genops.c:273
273	in genops.c
(gdb) 
#5  0x400634cc in _IO_getc (fp=0x804be08) at getc.c:38
38	getc.c: No such file or directory.
(gdb) 
#6  0x8048dcd in s_1paus (fin=0x804be08)
    at ../../../../g77-e/libf2c/libF77/s_paus.c:40
(gdb) 
#7  0x8048e92 in s_paus (s=0x804a4c0 "STOP ", n=0)
    at ../../../../g77-e/libf2c/libF77/s_paus.c:61
(gdb) 
#8  0x8048cbf in MAIN__ () at ar1.f:7
Current language:  auto; currently fortran
(gdb) p a
$1 = (( 0, 100, 200, 300, 400) ( 1, 101, 201, 301, 401) ( 2, 102, 202, 302, 402) ( 3, 103, 203, 303, 403) ( 4, 104, 204, 304, 404) ( 5, 105, 205, 305, 405) )
(gdb) p a(0,0)
$2 = 0
(gdb) p a(1,0)
$3 = 100
(gdb) p a(2,0)
$4 = 200
(gdb) p a(3,0)
$5 = 300
(gdb) p a(4,0)
$6 = 400
(gdb) p a(5,0)
$7 = 1
(gdb) p a(0,1)
$8 = 101                             <== all `p' output from here down WRONG!
(gdb) p a(1,1)
$9 = 201
(gdb) p a(2,1)
$10 = 301
(gdb) p a(3,1)
$11 = 401
(gdb) p a(4,1)
$12 = 2
(gdb) p a(0,2)
$13 = 202
(gdb) p a(1,2)
$14 = 302
(gdb) p a(2,2)
$15 = 402
(gdb) whatis a
type = real*4 (0:4,0:5)
(gdb) quit
The program is running.  Exit anyway? (y or n) y

Debugger finished
--------

-S output from Fortran source:
--------
	.file	"ar1.f"
	.version	"01.01"
.stabs "/home3/craig/gnu/play/",100,0,0,.Ltext0
.stabs "ar1.f",100,0,0,.Ltext0
.text
.Ltext0:
	.stabs	"gcc2_compiled.", 0x3c, 0, 0, 0
.stabs "int:t(0,1)=r(0,1);0020000000000;0017777777777;",128,0,0,0
.stabs "char:t(0,2)=r(0,2);0;255;",128,0,0,0
.stabs "long int:t(0,3)=r(0,1);0020000000000;0017777777777;",128,0,0,0
.stabs "unsigned int:t(0,4)=r(0,1);0000000000000;0037777777777;",128,0,0,0
.stabs "long unsigned int:t(0,5)=r(0,1);0000000000000;0037777777777;",128,0,0,0
.stabs "long long int:t(0,6)=r(0,1);01000000000000000000000;0777777777777777777777;",128,0,0,0
.stabs "long long unsigned int:t(0,7)=r(0,1);0000000000000;01777777777777777777777;",128,0,0,0
.stabs "short int:t(0,8)=r(0,8);-32768;32767;",128,0,0,0
.stabs "short unsigned int:t(0,9)=r(0,9);0;65535;",128,0,0,0
.stabs "signed char:t(0,10)=r(0,10);-128;127;",128,0,0,0
.stabs "unsigned char:t(0,11)=r(0,11);0;255;",128,0,0,0
.stabs "float:t(0,12)=r(0,1);4;0;",128,0,0,0
.stabs "double:t(0,13)=r(0,1);8;0;",128,0,0,0
.stabs "long double:t(0,14)=r(0,1);12;0;",128,0,0,0
.stabs "complex int:t(0,15)=s8real:(0,1),0,32;imag:(0,1),32,32;;",128,0,0,0
.stabs "complex float:t(0,16)=r(0,16);4;0;",128,0,0,0
.stabs "complex double:t(0,17)=r(0,17);8;0;",128,0,0,0
.stabs "complex long double:t(0,18)=r(0,18);12;0;",128,0,0,0
.stabs "void:t(0,19)=(0,19)",128,0,0,0
.stabs "integer:t(0,20)=r(0,1);0020000000000;0017777777777;",128,0,0,0
.stabs "unsigned:t(0,21)=r(0,1);0000000000000;0037777777777;",128,0,0,0
.stabs "byte:t(0,22)=r(0,22);-128;127;",128,0,0,0
.stabs "unsigned byte:t(0,23)=r(0,23);0;255;",128,0,0,0
.stabs "word:t(0,24)=r(0,24);-32768;32767;",128,0,0,0
.stabs "unsigned word:t(0,25)=r(0,25);0;65535;",128,0,0,0
.stabs "integer4:t(0,26)=r(0,1);01000000000000000000000;0777777777777777777777;",128,0,0,0
.stabs "unsigned4:t(0,27)=r(0,1);0000000000000;01777777777777777777777;",128,0,0,0
.stabs "logical:t(0,28)=r(0,1);0020000000000;0017777777777;",128,0,0,0
.stabs "logical2:t(0,29)=r(0,29);-128;127;",128,0,0,0
.stabs "logical3:t(0,30)=r(0,30);-32768;32767;",128,0,0,0
.stabs "logical4:t(0,31)=r(0,1);01000000000000000000000;0777777777777777777777;",128,0,0,0
.stabs "real:t(0,32)=r(0,1);4;0;",128,0,0,0
.stabs "double precision:t(0,33)=r(0,1);8;0;",128,0,0,0
.stabs "complex:t(0,34)=r(0,34);4;0;",128,0,0,0
.stabs "double complex:t(0,35)=r(0,35);8;0;",128,0,0,0
.stabs "__g77_f2c_integer:t(0,36)=r(0,1);0020000000000;0017777777777;",128,0,0,0
.stabs "__g77_f2c_address:t(0,37)=*(0,10)",128,0,0,0
.stabs "__g77_f2c_real:t(0,38)=r(0,1);4;0;",128,0,0,0
.stabs "__g77_f2c_doublereal:t(0,39)=r(0,1);8;0;",128,0,0,0
.stabs "__g77_f2c_complex:t(0,40)=r(0,40);4;0;",128,0,0,0
.stabs "__g77_f2c_doublecomplex:t(0,41)=r(0,41);8;0;",128,0,0,0
.stabs "__g77_f2c_longint:t(0,42)=r(0,1);01000000000000000000000;0777777777777777777777;",128,0,0,0
.stabs "__g77_f2c_logical:t(0,43)=r(0,1);0020000000000;0017777777777;",128,0,0,0
.stabs "__g77_f2c_flag:t(0,44)=r(0,1);0020000000000;0017777777777;",128,0,0,0
.stabs "__g77_f2c_ftnlen:t(0,45)=r(0,1);0020000000000;0017777777777;",128,0,0,0
.stabs "__g77_f2c_ftnint:t(0,46)=r(0,1);0020000000000;0017777777777;",128,0,0,0
.section	.rodata
.LC0:
.text
	.align 4
.stabs "MAIN__:F(0,19)",36,0,1,MAIN__
.globl MAIN__
	.type	 MAIN__,@function
MAIN__:
.stabn 68,0,1,.LM1-MAIN__
.LM1:
	pushl %ebp
	movl %esp,%ebp
	subl $164,%esp
	pushl %ebx
.stabn 68,0,1,.LM2-MAIN__
.LM2:
.LBB2:
.stabn 68,0,2,.LM3-MAIN__
.LM3:
.LBB3:
	movl $6,-140(%ebp)
	movl $0,-132(%ebp)
	.p2align 4,,7
.L3:
	decl -140(%ebp)
	cmpl $0,-140(%ebp)
	jge .L6
	jmp .L4
	.p2align 4,,7
.L6:
.stabn 68,0,3,.LM4-MAIN__
.LM4:
.LBB4:
	movl $5,-144(%ebp)
	movl $0,-136(%ebp)
	.p2align 4,,7
.L7:
	decl -144(%ebp)
	cmpl $0,-144(%ebp)
	jge .L10
	jmp .L5
	.p2align 4,,7
.L10:
.stabn 68,0,4,.LM5-MAIN__
.LM5:
	movl -136(%ebp),%eax
	movl %eax,%edx
	leal 0(,%edx,4),%eax
	movl -132(%ebp),%ecx
	movl %ecx,%edx
	sall $2,%edx
	addl %ecx,%edx
	leal 0(,%edx,4),%ecx
	addl %ecx,%eax
	leal -128(%ebp),%edx
	movl -136(%ebp),%ebx
	movl %ebx,%ecx
	sall $2,%ecx
	addl %ebx,%ecx
	leal 0(,%ecx,4),%ebx
	addl %ebx,%ecx
	leal 0(,%ecx,4),%ebx
	movl %ebx,%ecx
	addl -132(%ebp),%ecx
	movl %ecx,-148(%ebp)
	fildl -148(%ebp)
	fstps (%eax,%edx)
.stabn 68,0,5,.LM6-MAIN__
.LM6:
.L9:
	incl -136(%ebp)
	jmp .L7
	.p2align 4,,7
.L8:
.LBE4:
.stabn 68,0,6,.LM7-MAIN__
.LM7:
.L5:
	incl -132(%ebp)
	jmp .L3
	.p2align 4,,7
.L4:
.LBE3:
.stabn 68,0,7,.LM8-MAIN__
.LM8:
	addl $-8,%esp
	pushl $0
	pushl $.LC0
	call s_paus
	addl $16,%esp
.stabn 68,0,8,.LM9-MAIN__
.LM9:
	addl $-8,%esp
	pushl $0
	pushl $.LC0
	call s_stop
	addl $16,%esp
.LBE2:
.stabn 68,0,8,.LM10-MAIN__
.LM10:
	.p2align 4,,7
.L2:
	movl -168(%ebp),%ebx
	movl %ebp,%esp
	popl %ebp
	ret
.Lfe1:
	.size	 MAIN__,.Lfe1-MAIN__
.stabs "a:(0,47)=ar(0,20);0;5;(0,48)=ar(0,20);0;4;(0,32)",128,0,1,-128
.stabs "i:(0,20)",128,0,2,-132
.stabs "j:(0,20)",128,0,3,-136
.stabn 192,0,0,.LBB2-MAIN__
.stabs "__g77_do_0:(0,20)",128,0,2,-140
.stabn 192,0,0,.LBB3-MAIN__
.stabs "__g77_do_1:(0,20)",128,0,3,-144
.stabn 192,0,0,.LBB4-MAIN__
.stabn 224,0,0,.LBE4-MAIN__
.stabn 224,0,0,.LBE3-MAIN__
.stabn 224,0,0,.LBE2-MAIN__
.Lscope0:
.stabs "",36,0,0,.Lscope0-MAIN__
	.text
	.stabs "",100,0,0,Letext
Letext:
	.ident	"GCC: (GNU) gcc-2.95 19990524 (prerelease)"
--------

a bit more of a (new) gdb session showing that gdb handles the same
code fine in C language mode:
--------
(gdb) set lang c
(gdb) p a
$1 = {{0, 100, 200, 300, 400}, {1, 101, 201, 301, 401}, {2, 102, 202, 302, 
    402}, {3, 103, 203, 303, 403}, {4, 104, 204, 304, 404}, {5, 105, 205, 305, 
    405}}
(gdb) p a[0][0]
$2 = 0
(gdb) p a[0][1]
$3 = 100
(gdb) p a[0][4]
$4 = 400
(gdb) p a[1][0]
$5 = 1
(gdb) p a[1][1]
$6 = 101
(gdb) whatis a
type = real [6][5]
(gdb) 
--------

Re: gdb and g77

[craig]

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

Re: gdb and g77

[Per Bothner]

Jeffrey A Law <law@cygnus.com> writes:

The way it *should* work IMNSHO:
* A f77 3*2 array should be represented internally (tree nodes etc)
the same as a C 2*3 array:  I.e. a 2-element array of 3-element arrays.
* The stabs should be the same for a f77 3*2 array as for a C 2*3 array.
* The internal Gdb representation of a f77 3*2 array should be the
asme as a C 2*3 array.
* When Gdb evaluates the f77 experession A(i,j) it should do the same
thing as when evaluating the C expression A[j][i].  This re-arranging
can be done by the expression parsing, or (by using a different
expression opcode) in the expression evaluator.  Because the parser
cannot distinguish a function call from an array indexing operation,
it does the latter, using the opcode OP_F77_UNDETERMINED_ARGLIST.

Rationale:  Logically, a f77 3*2 array is equivalent to a C 2*3 array
- it is just the order of indexes that are different.  The difference is
not one of types, but of expression syntax.  Hence the types should
be represented the same.

I worked on this some years ago, trying to clean up some code from
Motorola, but it has been a while, and may well have bit-rotten
- or been wrong in the first place.
-- 
	--Per Bothner
bothner@pacbell.net     http://home.pacbell.net/bothner/

Re: gdb and g77

[Jeffrey A Law]

  In message < m2yahmlidn.fsf@magnus.cygnus.com >you write:
  > Jeffrey A Law <law@cygnus.com> writes:
  > 
  > The way it *should* work IMNSHO:
  > * A f77 3*2 array should be represented internally (tree nodes etc)
  > the same as a C 2*3 array:  I.e. a 2-element array of 3-element arrays.
It is.

  > * The stabs should be the same for a f77 3*2 array as for a C 2*3 array.
They are (verified by Craig & myself).

  > * The internal Gdb representation of a f77 3*2 array should be the
  > asme as a C 2*3 array.
  > * When Gdb evaluates the f77 experession A(i,j) it should do the same
  > thing as when evaluating the C expression A[j][i].  This re-arranging
  > can be done by the expression parsing, or (by using a different
  > expression opcode) in the expression evaluator.  Because the parser
  > cannot distinguish a function call from an array indexing operation,
  > it does the latter, using the opcode OP_F77_UNDETERMINED_ARGLIST.
These are where we'll start concentrating our efforts now that we're
fairly sure the stabs are reasonable.

jeff

Re: gdb and g77

[David Edelsohn]

	Is this an issue where C specifies row-major arrays and Fortran
specifies column-major arrays?  The subscripts would appear to be reversed
if gdb did not set the language type correctly or handle the row-major
versus column-major specification.

David

Re: gdb bug in Fortran language mode [was Re: gdb and g77]

[Stan Shebs]

   From: craig@jcb-sc.com
   Date: 15 Jun 1999 00:06:28 -0000

   The summary: I believe gdb is the culprit, specifically, its Fortran
   language mode doesn't handle multi-dimension arrays (for stabs debugging
   anyway) correctly.

OK, if you're satisfied that GCC's output is correct, then we can take
over on the GDB side.  GDB's Fortran support hasn't been touched in a
while, and the original contribution was only tested with Motorola or
AIX compilers or something like that.

								Stan

Re: gdb bug in Fortran language mode [was Re: gdb and g77]

[Jeffrey A Law]

  In message < 199906150016.RAA06796@andros.cygnus.com >you write:
  > OK, if you're satisfied that GCC's output is correct, then we can take
  > over on the GDB side.  GDB's Fortran support hasn't been touched in a
  > while, and the original contribution was only tested with Motorola or
  > AIX compilers or something like that.
It's looking more and more like a gdb issue.  I'm going to grope around and
see if I can come up with a copy of HP Fortran for some minimal testing.

jeff

Re: gdb and g77

[craig]

>> (Yes, it is a "C-ish" back end, but it does have a higher-level array
>> facility than C itself does, insofar that C cannot represent arrays
>> of arrays -- instead, it represents arrays of pointers to arrays, for
>> example.)
>
>Huh?  C can represent arrays of arrays just fine.

That's news to me.  Care to show how?  Note I said *represent* -- not
*implement* -- as any language that provides single-dimensional arrays
can be used to *implement* multi-dimensional arrays.

So, basically, what I'm asking is, what is the C notation that denotes
the equivalent to Fortran's

  REAL A(5,6)

(except that it's row-major, of course) *including* the fact that the
storage takes up 30 units of memory *and* the fact that the same array
declaration works just fine regardless of whether A is a local variable,
in common (external) storage, or a dummy argument (the last case being
especially notable)?

Reason I ask is, in the past, C programmers have occasionally taken
to comp.lang.fortran showing how "easy" it is to cons up a set of
preprocessor macros to make C *look* like it has multi-dimensional arrays
a la Fortran.  I'm sure they'd be quite surprised to learn that C
had them all along!

        tq vm, (burley)

Re: gdb and g77

[Richard Henderson]

On Mon, Jun 14, 1999 at 12:55:31AM -0600, Jeffrey A Law wrote:
>   1. gcc emits incorrect debug records.
> 
>   2. gdb interprets the debug records incorrectly.

3.  Gdb's fortran mode prints arrays in a confusing manner.  Columns
    are printed first, since they change more frequently.  But they 
    are printed in rows.

This was the conclusion I came to doing specfp95 debugging a 
few months ago, based on the fact that printing seemed skewed,
but expression evaluation and type info (as reported by ptype)
seemed fine.

I'm really very surprised to hear a report that gdb `works ok'
with the system compiler.

Another way to test debug info in gdb is to `set lang c' and 
see if things look more reasonable.


r~

Re: gdb and g77

[Tim Schmielau]

[-- Attachment #1: Type: text/plain, Size: 2359 bytes --]

> Well, it looks like there's general doubt on this list regarding the
> statement that gdb works fine with "other" Fortran compilers.
> 
> 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?

Though I didn't make that assertment, I just tested Portland Group's PGF77
on Linux/Intel against gdb, and indeed found it working.
I used the following short program:

      IMPLICIT NONE
      REAL x(5,6)
      INTEGER i,j

      DO i=1,5
         DO j=1,6
            x(i,j) = i+j*0.1
         ENDDO
      ENDDO
      WRITE(*,*) "array filled."
      END

Debug session log follows:

  > pgf77 -g arrtest.f
  > gdb a.out 
  GNU gdb 4.17.0.11 with Linux support
  Copyright 1998 Free Software Foundation, Inc.
  GDB is free software, covered by the GNU General Public License, and you
  are
  welcome to change it and/or distribute copies of it under certain
  conditions.
  Type "show copying" to see the conditions.
  There is absolutely no warranty for GDB.  Type "show warranty" for
  details.
  This GDB was configured as "i686-pc-linux-gnu"...
  (gdb) b MAIN
  Breakpoint 1 at 0x8048d46: file arrtest.f, line 5.
  (gdb) r
  Starting program: /users/hoptik2/tim/test/a.out 
  
  Breakpoint 1, MAIN () at arrtest.f:5
  5             DO i=1,5
  Current language:  auto; currently fortran
  (gdb) b 10
  Breakpoint 2 at 0x8048dbb: file arrtest.f, line 10.
  (gdb) c
  Continuing.
  
  Breakpoint 2, MAIN () at arrtest.f:10
  10            WRITE(*,*) "array filled."
  (gdb) ptype x
  type = real*4 (6,5)
  (gdb) print x(1,1)
  $1 = 1.10000002
  (gdb) print x(1,2)
  $2 = 1.20000005
  (gdb) print x(2,1)
  $3 = 2.0999999

while the same program, compiled with g77, gives

  > g77 -g arrtest.f
  > gdb a.out
      ...
  (gdb) ptype x
  type = real*4 (5,6)
  (gdb) print x(1,1)
  $1 = 1.10000002
  (gdb) print x(2,1)
  $2 = 2.0999999
  (gdb) print x(1,2)
  $3 = 2.20000005

with the last being wrong. Note also the different outputs from ptype.
Output from

  > pgf77 -g -S arrtest.f

is attached.

hope this helps,
Tim Schmielau (tim@physik3.uni-rostock.de)

[-- Attachment #2: arrtest.s.gz --]
[-- Type: application/x-gzip, Size: 1174 bytes --]

Re: gdb and g77

[craig]

>  When g77 emits debug info for arrays, the dimensions are reversed.  If
>your array is palindromic, ie "dimension a(10,20,10)", it will work OK,
>but otherwise gdb will be looking at the wrong memory location for the
>data.  I originally thought the problem was with gdb reversing the
>dimensions, but after building gdb on an RS6K, it correctly read the
>dimension info from the native RS6K compiler.  Ergo g77 is incorrect.

Sounds reasonable, though the likely cause of the problem is the gcc
back end.  The g77 front end (presumably) passes to the back end
the proper info on the array, else there'd be *huge* problems, either
in correctness or performance.  What is probably happening, then, is
that the back end's debug modules (sdbout.c, dbxout.c, dwarfout.c,
dwarf2out.c, etc.) aren't coping properly with multi-dimensional
arrays.

But I'm speaking on this without actually looking at any of the code,
or -g output, etc.  I'm real busy this weekend, but will try to catch
up on things like this shortly, though the fact that nobody else seems
to have found the problem already suggests that it isn't an easy problem
to spot!

        tq vm, (burley)

Re: gdb and g77

[Dave Love]

>>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:

 Stan> Argh - gdb-patches would have been a better destination.  

I wasn't sending a patch and I don't know where one would learn about
that address.  It's not in MAILINGLISTS or the released gdb/README and
I'm pretty sure I DTRT according to whatever version of gdb I had at
the time.
  
 Stan> HP is busy working on Fortran support in their version of GDB,
 Stan> so there is probably some duplicated work going on now, sigh.

Not from me any more.

I hope HP stuff isn't going to interfere with potential g77 support.
HP Fortran conventions also are significantly different from g77's.

Re: gdb and g77

[craig]

>Though I didn't make that assertment, I just tested Portland Group's PGF77
>on Linux/Intel against gdb, and indeed found it working.

Hmm, I consider gdb to *not* be working with pgf77.  Consider:

>      REAL x(5,6)
[...]
>  > pgf77 -g arrtest.f
>  > gdb a.out 
[...]
>  (gdb) ptype x
>  type = real*4 (6,5)

That's the wrong answer!  But consider:

>  > g77 -g arrtest.f
>  > gdb a.out
[...]
>  (gdb) ptype x
>  type = real*4 (5,6)

That's the *correct* answer!

Perhaps pgf77 works around one bug in gdb and hits another, while g77
happens to do the opposite.

        tq vm, (burley)

Re: gdb and g77

[Tim Schmielau]

> Hmm, I consider gdb to *not* be working with pgf77.
> [...]
> Perhaps pgf77 works around one bug in gdb and hits another, while g77
> happens to do the opposite.

Yup, pgf77's code fails printing the whole array,

  (gdb) print x
  $17 = (( 1.10000002, 2.0999999, 3.0999999, 4.0999999, 5.0999999,
  1.20000005) ( 2.20000005, 3.20000005, 4.19999981, 5.19999981,1.29999995,
  2.29999995) ( 3.29999995, 4.30000019, 5.30000019, 1.39999998, 2.4000001,
  3.4000001) ( 4.4000001, 5.4000001, 1.5, 2.5, 3.5, 4.5) ( 5.5,
  1.60000002, 2.5999999, 3.5999999, 4.5999999, 5.5999999) )

while g77's succeeds

  (gdb) print x
  $2 = (( 1.10000002, 2.0999999, 3.0999999, 4.0999999, 5.0999999) (
  1.20000005, 2.20000005, 3.20000005, 4.19999981, 5.19999981) (
  1.29999995, 2.29999995, 3.29999995, 4.30000019, 5.30000019) ( 
  1.39999998, 2.4000001, 3.4000001, 4.4000001, 5.4000001) ( 1.5, 2.5, 3.5,
  4.5, 5.5) ( 1.60000002, 2.5999999, 3.5999999, 4.5999999, 5.5999999) )

So there really seems to be no way of teaching gdb both things.

By the way, PG's own debugger pgdbg works correctly on both pgf77's
and g77's code, so they seem to have done a fairly complete workaround (as
far as possible).
This suggests they also have investigated this point and haven't found a
better way of teaching gdb, either. 

Tim Schmielau (tim@physik3.uni-rostock.de)

Re: gdb and g77

[Stan Shebs]

   From: Dave Love <d.love@dl.ac.uk>
   Date: 17 Jun 1999 20:22:52 +0100

   >>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:

    Stan> Argh - gdb-patches would have been a better destination.  

   I wasn't sending a patch and I don't know where one would learn about
   that address.  It's not in MAILINGLISTS or the released gdb/README and
   I'm pretty sure I DTRT according to whatever version of gdb I had at
   the time.

I'm not sure what "MAILINGLISTS" is supposed to be, but that's a good
point about gdb-patches not being documented well - it's in the internals
manual and on the sourceware web page, but prior to sourceware it was
only mentioned in the semi-secret ftp location, which most people didn't
know about (it seems ridiculous, now, that anybody could have thought
there was some advantage to keeping snapshots secret...).

   I hope HP stuff isn't going to interfere with potential g77 support.
   HP Fortran conventions also are significantly different from g77's.

Yes, that's why I want to stay on top of all this right now - HP is
preparing to submit Fortran support patches derived from their WDB
release, and it would be bad to have any of that collide with g77
support.

								Stan

Re: gdb and g77

[Stan Shebs]

Dave Love <d.love@dl.ac.uk> writes:

> The gdb support was written for a compiler with different conventions
> from g77.  (I sent a copy of the paper on it a while back.)  I started
> working on changes long ago but couldn't get a response from bug-gdb
> about incorporating changes and no-one else seemed interested, so I
> dropped it and probably no longer have the work.

Argh - gdb-patches would have been a better destination.  I would have
loved to get the fixes.  HP is busy working on Fortran support in
their version of GDB, so there is probably some duplicated work going
on now, sigh.

								Stan

Re: gdb and g77

[craig]

> I get wrong answers from gdb when printing elements of a 3-dimensional
>Fortran (g77)
> array.  Is this a known problem, or am I missing something?  My
>versions of g77 and gdb came with RedHat Ver 6.0 Linux.

It's hard to tell without an example.  Offhand, I don't think *that*
particular problem is know, though other g77+gdb problems are, to
varying degrees, known (e.g. gdb 4.18 seems to not print complex
variables correctly), and one or more of these might be what you are,
in fact, seeing.

        tq vm, (burley)

Re: gdb and g77

[craig]

>  When g77 emits debug info for arrays, the dimensions are reversed.  If
>your array is palindromic, ie "dimension a(10,20,10)", it will work OK,
>but otherwise gdb will be looking at the wrong memory location for the
>data.  I originally thought the problem was with gdb reversing the
>dimensions, but after building gdb on an RS6K, it correctly read the
>dimension info from the native RS6K compiler.  Ergo g77 is incorrect.

It seems the above analysis is wrong, but I've been getting bounces
from Andy's email address above, so I don't know whether Andy's seen
the ensuing discussion (whether he's on the egcs mailing list).

It'll be awfully sad if it turns out the Fortran mode in gdb was
*designed* wrongly, such that making it correct (which would help g77)
would break it for other compilers.

        tq vm, (burley)

Re: gdb and g77

[Dave Love]

>>>>> "JCB" == craig  <craig@jcb-sc.com> writes:

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

The gdb support was written for a compiler with different conventions
from g77.  (I sent a copy of the paper on it a while back.)  I started
working on changes long ago but couldn't get a response from bug-gdb
about incorporating changes and no-one else seemed interested, so I
dropped it and probably no longer have the work.

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

I can't remember the details, but array references are quite
broken, particularly for dummy args.  They're interpreted as function
calls in Fortran mode and can crash gdb in C mode with assumed-size
arrays; e.g. in something like this, look at a and b in foo with
`print' and `whatis'.

      real a(3)
      data a /1,2,3/
      call foo(a, a)
      end
      subroutine foo(a, b)
      real a(3), b(*)
      print *, a(1), b(1)
      end

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

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

Generally there are Fortran-specific stabs and DWARFism which should
probably be emitted but aren't (for COMMON in particular).  Also
name-mangling needs treating.

For stabs, the online ( http://docs.sun.com/ ) Sun Fortran docs explain
how they deal with Fortran and one can generate sample assembler.
AFAIR, gdb works reasonably well with SunPro f77 (stabs) but doesn't
with MIPSpro (DWARF, at least now).

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

I don't know about this case, but I think the job needs doing
properly, and that's a fair amount of work.  I presume that changes
could now be got into gdb, at least.

gdb and g77

[Peter Hirsch]

 I get wrong answers from gdb when printing elements of a 3-dimensional
Fortran (g77)
 array.  Is this a known problem, or am I missing something?  My
versions of g77 and gdb came with RedHat Ver 6.0 Linux.

Re: gdb and g77

[Andrew Vaught]

>> I get wrong answers from gdb when printing elements of a 3-dimensional
>>Fortran (g77)
>> array.  Is this a known problem, or am I missing something?  My
>>versions of g77 and gdb came with RedHat Ver 6.0 Linux.
>
>It's hard to tell without an example.  Offhand, I don't think *that*
>particular problem is know, though other g77+gdb problems are, to
>varying degrees, known (e.g. gdb 4.18 seems to not print complex
>variables correctly), and one or more of these might be what you are,
>in fact, seeing.
>
>        tq vm, (burley)

  When g77 emits debug info for arrays, the dimensions are reversed.  If
your array is palindromic, ie "dimension a(10,20,10)", it will work OK,
but otherwise gdb will be looking at the wrong memory location for the
data.  I originally thought the problem was with gdb reversing the
dimensions, but after building gdb on an RS6K, it correctly read the
dimension info from the native RS6K compiler.  Ergo g77 is incorrect.

         Andy

Re: gdb and g77

[Stan Shebs]

   From: Dave Love <d.love@dl.ac.uk>
   Date: 17 Jun 1999 20:22:52 +0100

   >>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:

    Stan> Argh - gdb-patches would have been a better destination.  

   I wasn't sending a patch and I don't know where one would learn about
   that address.  It's not in MAILINGLISTS or the released gdb/README and
   I'm pretty sure I DTRT according to whatever version of gdb I had at
   the time.

I'm not sure what "MAILINGLISTS" is supposed to be, but that's a good
point about gdb-patches not being documented well - it's in the internals
manual and on the sourceware web page, but prior to sourceware it was
only mentioned in the semi-secret ftp location, which most people didn't
know about (it seems ridiculous, now, that anybody could have thought
there was some advantage to keeping snapshots secret...).

   I hope HP stuff isn't going to interfere with potential g77 support.
   HP Fortran conventions also are significantly different from g77's.

Yes, that's why I want to stay on top of all this right now - HP is
preparing to submit Fortran support patches derived from their WDB
release, and it would be bad to have any of that collide with g77
support.

								Stan

Re: gdb and g77

[Dave Love]

>>>>> "Stan" == Stan Shebs <shebs@cygnus.com> writes:

 Stan> Argh - gdb-patches would have been a better destination.  

I wasn't sending a patch and I don't know where one would learn about
that address.  It's not in MAILINGLISTS or the released gdb/README and
I'm pretty sure I DTRT according to whatever version of gdb I had at
the time.
  
 Stan> HP is busy working on Fortran support in their version of GDB,
 Stan> so there is probably some duplicated work going on now, sigh.

Not from me any more.

I hope HP stuff isn't going to interfere with potential g77 support.
HP Fortran conventions also are significantly different from g77's.

Re: gdb and g77

[Tim Schmielau]

> Hmm, I consider gdb to *not* be working with pgf77.
> [...]
> Perhaps pgf77 works around one bug in gdb and hits another, while g77
> happens to do the opposite.

Yup, pgf77's code fails printing the whole array,

  (gdb) print x
  $17 = (( 1.10000002, 2.0999999, 3.0999999, 4.0999999, 5.0999999,
  1.20000005) ( 2.20000005, 3.20000005, 4.19999981, 5.19999981,1.29999995,
  2.29999995) ( 3.29999995, 4.30000019, 5.30000019, 1.39999998, 2.4000001,
  3.4000001) ( 4.4000001, 5.4000001, 1.5, 2.5, 3.5, 4.5) ( 5.5,
  1.60000002, 2.5999999, 3.5999999, 4.5999999, 5.5999999) )

while g77's succeeds

  (gdb) print x
  $2 = (( 1.10000002, 2.0999999, 3.0999999, 4.0999999, 5.0999999) (
  1.20000005, 2.20000005, 3.20000005, 4.19999981, 5.19999981) (
  1.29999995, 2.29999995, 3.29999995, 4.30000019, 5.30000019) ( 
  1.39999998, 2.4000001, 3.4000001, 4.4000001, 5.4000001) ( 1.5, 2.5, 3.5,
  4.5, 5.5) ( 1.60000002, 2.5999999, 3.5999999, 4.5999999, 5.5999999) )

So there really seems to be no way of teaching gdb both things.

By the way, PG's own debugger pgdbg works correctly on both pgf77's
and g77's code, so they seem to have done a fairly complete workaround (as
far as possible).
This suggests they also have investigated this point and haven't found a
better way of teaching gdb, either. 

Tim Schmielau (tim@physik3.uni-rostock.de)

Re: gdb and g77

[craig]

>Though I didn't make that assertment, I just tested Portland Group's PGF77
>on Linux/Intel against gdb, and indeed found it working.

Hmm, I consider gdb to *not* be working with pgf77.  Consider:

>      REAL x(5,6)
[...]
>  > pgf77 -g arrtest.f
>  > gdb a.out 
[...]
>  (gdb) ptype x
>  type = real*4 (6,5)

That's the wrong answer!  But consider:

>  > g77 -g arrtest.f
>  > gdb a.out
[...]
>  (gdb) ptype x
>  type = real*4 (5,6)

That's the *correct* answer!

Perhaps pgf77 works around one bug in gdb and hits another, while g77
happens to do the opposite.

        tq vm, (burley)

Re: gdb and g77

[Stan Shebs]

Dave Love <d.love@dl.ac.uk> writes:

> The gdb support was written for a compiler with different conventions
> from g77.  (I sent a copy of the paper on it a while back.)  I started
> working on changes long ago but couldn't get a response from bug-gdb
> about incorporating changes and no-one else seemed interested, so I
> dropped it and probably no longer have the work.

Argh - gdb-patches would have been a better destination.  I would have
loved to get the fixes.  HP is busy working on Fortran support in
their version of GDB, so there is probably some duplicated work going
on now, sigh.

								Stan

Re: gdb and g77

[Tim Schmielau]

> Well, it looks like there's general doubt on this list regarding the
> statement that gdb works fine with "other" Fortran compilers.
> 
> 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?

Though I didn't make that assertment, I just tested Portland Group's PGF77
on Linux/Intel against gdb, and indeed found it working.
I used the following short program:

      IMPLICIT NONE
      REAL x(5,6)
      INTEGER i,j

      DO i=1,5
         DO j=1,6
            x(i,j) = i+j*0.1
         ENDDO
      ENDDO
      WRITE(*,*) "array filled."
      END

Debug session log follows:

  > pgf77 -g arrtest.f
  > gdb a.out 
  GNU gdb 4.17.0.11 with Linux support
  Copyright 1998 Free Software Foundation, Inc.
  GDB is free software, covered by the GNU General Public License, and you
  are
  welcome to change it and/or distribute copies of it under certain
  conditions.
  Type "show copying" to see the conditions.
  There is absolutely no warranty for GDB.  Type "show warranty" for
  details.
  This GDB was configured as "i686-pc-linux-gnu"...
  (gdb) b MAIN
  Breakpoint 1 at 0x8048d46: file arrtest.f, line 5.
  (gdb) r
  Starting program: /users/hoptik2/tim/test/a.out 
  
  Breakpoint 1, MAIN () at arrtest.f:5
  5             DO i=1,5
  Current language:  auto; currently fortran
  (gdb) b 10
  Breakpoint 2 at 0x8048dbb: file arrtest.f, line 10.
  (gdb) c
  Continuing.
  
  Breakpoint 2, MAIN () at arrtest.f:10
  10            WRITE(*,*) "array filled."
  (gdb) ptype x
  type = real*4 (6,5)
  (gdb) print x(1,1)
  $1 = 1.10000002
  (gdb) print x(1,2)
  $2 = 1.20000005
  (gdb) print x(2,1)
  $3 = 2.0999999

while the same program, compiled with g77, gives

  > g77 -g arrtest.f
  > gdb a.out
      ...
  (gdb) ptype x
  type = real*4 (5,6)
  (gdb) print x(1,1)
  $1 = 1.10000002
  (gdb) print x(2,1)
  $2 = 2.0999999
  (gdb) print x(1,2)
  $3 = 2.20000005

with the last being wrong. Note also the different outputs from ptype.
Output from

  > pgf77 -g -S arrtest.f

is attached.

hope this helps,
Tim Schmielau (tim@physik3.uni-rostock.de)

Re: gdb and g77

[craig]

>  When g77 emits debug info for arrays, the dimensions are reversed.  If
>your array is palindromic, ie "dimension a(10,20,10)", it will work OK,
>but otherwise gdb will be looking at the wrong memory location for the
>data.  I originally thought the problem was with gdb reversing the
>dimensions, but after building gdb on an RS6K, it correctly read the
>dimension info from the native RS6K compiler.  Ergo g77 is incorrect.

It seems the above analysis is wrong, but I've been getting bounces
from Andy's email address above, so I don't know whether Andy's seen
the ensuing discussion (whether he's on the egcs mailing list).

It'll be awfully sad if it turns out the Fortran mode in gdb was
*designed* wrongly, such that making it correct (which would help g77)
would break it for other compilers.

        tq vm, (burley)

Re: gdb and g77

[Dave Love]

>>>>> "JCB" == craig  <craig@jcb-sc.com> writes:

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

The gdb support was written for a compiler with different conventions
from g77.  (I sent a copy of the paper on it a while back.)  I started
working on changes long ago but couldn't get a response from bug-gdb
about incorporating changes and no-one else seemed interested, so I
dropped it and probably no longer have the work.

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

I can't remember the details, but array references are quite
broken, particularly for dummy args.  They're interpreted as function
calls in Fortran mode and can crash gdb in C mode with assumed-size
arrays; e.g. in something like this, look at a and b in foo with
`print' and `whatis'.

      real a(3)
      data a /1,2,3/
      call foo(a, a)
      end
      subroutine foo(a, b)
      real a(3), b(*)
      print *, a(1), b(1)
      end

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

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

Generally there are Fortran-specific stabs and DWARFism which should
probably be emitted but aren't (for COMMON in particular).  Also
name-mangling needs treating.

For stabs, the online ( http://docs.sun.com/ ) Sun Fortran docs explain
how they deal with Fortran and one can generate sample assembler.
AFAIR, gdb works reasonably well with SunPro f77 (stabs) but doesn't
with MIPSpro (DWARF, at least now).

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

I don't know about this case, but I think the job needs doing
properly, and that's a fair amount of work.  I presume that changes
could now be got into gdb, at least.

Re: gdb and g77

[craig]

>  When g77 emits debug info for arrays, the dimensions are reversed.  If
>your array is palindromic, ie "dimension a(10,20,10)", it will work OK,
>but otherwise gdb will be looking at the wrong memory location for the
>data.  I originally thought the problem was with gdb reversing the
>dimensions, but after building gdb on an RS6K, it correctly read the
>dimension info from the native RS6K compiler.  Ergo g77 is incorrect.

Sounds reasonable, though the likely cause of the problem is the gcc
back end.  The g77 front end (presumably) passes to the back end
the proper info on the array, else there'd be *huge* problems, either
in correctness or performance.  What is probably happening, then, is
that the back end's debug modules (sdbout.c, dbxout.c, dwarfout.c,
dwarf2out.c, etc.) aren't coping properly with multi-dimensional
arrays.

But I'm speaking on this without actually looking at any of the code,
or -g output, etc.  I'm real busy this weekend, but will try to catch
up on things like this shortly, though the fact that nobody else seems
to have found the problem already suggests that it isn't an easy problem
to spot!

        tq vm, (burley)

Re: gdb and g77

[Andrew Vaught]

>> I get wrong answers from gdb when printing elements of a 3-dimensional
>>Fortran (g77)
>> array.  Is this a known problem, or am I missing something?  My
>>versions of g77 and gdb came with RedHat Ver 6.0 Linux.
>
>It's hard to tell without an example.  Offhand, I don't think *that*
>particular problem is know, though other g77+gdb problems are, to
>varying degrees, known (e.g. gdb 4.18 seems to not print complex
>variables correctly), and one or more of these might be what you are,
>in fact, seeing.
>
>        tq vm, (burley)

  When g77 emits debug info for arrays, the dimensions are reversed.  If
your array is palindromic, ie "dimension a(10,20,10)", it will work OK,
but otherwise gdb will be looking at the wrong memory location for the
data.  I originally thought the problem was with gdb reversing the
dimensions, but after building gdb on an RS6K, it correctly read the
dimension info from the native RS6K compiler.  Ergo g77 is incorrect.

         Andy

Re: gdb and g77

[craig]

> I get wrong answers from gdb when printing elements of a 3-dimensional
>Fortran (g77)
> array.  Is this a known problem, or am I missing something?  My
>versions of g77 and gdb came with RedHat Ver 6.0 Linux.

It's hard to tell without an example.  Offhand, I don't think *that*
particular problem is know, though other g77+gdb problems are, to
varying degrees, known (e.g. gdb 4.18 seems to not print complex
variables correctly), and one or more of these might be what you are,
in fact, seeing.

        tq vm, (burley)

gdb and g77

[Peter Hirsch]

 I get wrong answers from gdb when printing elements of a 3-dimensional
Fortran (g77)
 array.  Is this a known problem, or am I missing something?  My
versions of g77 and gdb came with RedHat Ver 6.0 Linux.