[RFC]: Testcase for gdb's handling of Fortran's column-first array

[RFC]: Testcase for gdb's handling of Fortran's column-first array

[Wu Zhou]

As we all might know, the memory layout of Fortran's multi-dimension array 
is different than that of C language.  This testcase is intended to verify 
whether gdb could correctly handle Fortran's column-first array.  It 
defines two 2-dimension array, one of type integer and the other type 
real.  Then it will verify that gdb's could inteprete the arrays in the 
same layout.  It also makes some changes to some specified element, and 
then verify that it changed the correct element in the memory.

OK.  With all these said, here is the patch.  I had tested it on FC4, it 
reported no failure.  But however I _did_ found a old gdb (6.1 maybe) 
handle this incorrectly.  So this testcase still make senses.  OK to 
commit?

2005-11-02  Wu Zhou  <woodzltc@cn.ibm.com>

	* gdb.fortran/dim-order.f: New file.
	* gdb.fortran/dim-order.exp: New testcase.

Index: gdb.fortran/dim-order.f
===================================================================
RCS file: gdb.fortran/dim-order.f
diff -N gdb.fortran/dim-order.f
*** /dev/null	1 Jan 1970 00:00:00 -0000
--- gdb.fortran/dim-order.f	2 Nov 2005 05:37:02 -0000
***************
*** 0 ****
--- 1,45 ----
+ c Copyright 2005 Free Software Foundation, Inc.
+ 
+ c This program is free software; you can redistribute it and/or modify
+ c it under the terms of the GNU General Public License as published by
+ c the Free Software Foundation; either version 2 of the License, or
+ c (at your option) any later version.
+ c
+ c This program is distributed in the hope that it will be useful,
+ c but WITHOUT ANY WARRANTY; without even the implied warranty of
+ c MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ c GNU General Public License for more details.
+ c
+ c You should have received a copy of the GNU General Public License
+ c along with this program; if not, write to the Free Software
+ c Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ 
+ c Ihis file is the F77 source file for dim-order.exp.  It was written
+ c by Wu Zhou. (woodzltc@cn.ibm.com)
+ 
+       program dimorder 
+ 
+       integer aa, aaa
+       dimension aa(3,4)
+       real bb
+       dimension bb(3,4)
+ 
+ c To initialize the above multi-dimension arrays.
+       do j = 1,4
+         do i = 1,3
+           aa(i,j) = j * i
+           bb(i,j) = j * i
+         end do 
+       end do
+ 
+ c To transfer aa as parameter into subroutine sub.
+       call sub(aa)
+ 
+       end program 
+ 
+       subroutine sub(a)
+       integer a
+       dimension a(12)
+         print *, "This is in the subroutine"
+         print *,(a(i),i=1,12)
+       end
Index: gdb.fortran/dim-order.exp
===================================================================
RCS file: gdb.fortran/dim-order.exp
diff -N gdb.fortran/dim-order.exp
*** /dev/null	1 Jan 1970 00:00:00 -0000
--- gdb.fortran/dim-order.exp	2 Nov 2005 05:37:02 -0000
***************
*** 0 ****
--- 1,71 ----
+ # Copyright 2005 Free Software Foundation, Inc.
+ 
+ # This program is free software; you can redistribute it and/or modify
+ # it under the terms of the GNU General Public License as published by
+ # the Free Software Foundation; either version 2 of the License, or
+ # (at your option) any later version.
+ # 
+ # This program is distributed in the hope that it will be useful,
+ # but WITHOUT ANY WARRANTY; without even the implied warranty of
+ # MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+ # GNU General Public License for more details.
+ # 
+ # You should have received a copy of the GNU General Public License
+ # along with this program; if not, write to the Free Software
+ # Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.  
+ 
+ # This file was written by Wu Zhou. (woodzltc@cn.ibm.com)
+ 
+ # This file is part of the gdb testsuite.  It contains test for verifying
+ # whether gdb can handle Fortran's column-first multi-dimensions array.
+ 
+ if $tracelevel then {
+ 	strace $tracelevel
+ }
+ 
+ set testfile "dim-order"
+ set srcfile ${testfile}.f
+ set binfile ${objdir}/${subdir}/${testfile}
+ 
+ if  { [gdb_compile "${srcdir}/${subdir}/${srcfile}" "${binfile}" executable {debug f77 quiet}] != "" } {
+     untested "Couldn't compile ${srcfile}"
+     return -1
+ }
+ 
+ gdb_exit
+ gdb_start
+ gdb_reinitialize_dir $srcdir/$subdir
+ gdb_load ${binfile}
+ 
+ if ![runto MAIN__] then {
+     perror "couldn't run to breakpoint MAIN__"
+     continue
+ }
+ 
+ set bp_location [gdb_get_line_number "call"]
+ gdb_test "break $bp_location" \
+     "Breakpoint.*at.* file .*$srcfile, line $bp_location\\." \
+     "breakpoint at subroutine call"
+ gdb_test "continue" \
+     "Continuing\\..*Breakpoint.*" \
+     "continue to the breakpoint at call"
+ 
+ gdb_test "print aa" ".*1 =.+1, 2, 3.+2, 4, 6.+3, 6, 9.+4, 8, 12.+" "print two-dimensions integer array aa"
+ gdb_test "print bb" ".*2 =.+1, 2, 3.+2, 4, 6.+3, 6, 9.+4, 8, 12.+" "print two-dimensions float array bb"
+ 
+ send_gdb "set var aa(3,2)=32\n"
+ gdb_expect {
+     -re "$gdb_prompt $" { pass "set aa(3,2) to 32" }
+     timeout	{fail "set aa(3,2) to 32" }
+   }
+ gdb_test "print aa" ".*3 =.*1, 2, 3.+2, 4, 32.+3, 6, 9.+4, 8, 12.+" "check array aa after the above change"
+ 
+ send_gdb "set var bb(3,2)=32.0\n"
+ gdb_expect {
+     -re "$gdb_prompt $"	{ pass "set bb(3,2) to 32.0" }
+     timeout	{fail "set bb(3,2) to 32.0" }
+   }
+ gdb_test "print bb" ".*4 = .*1, 2, 3.+2, 4, 32.+3, 6, 9.+4, 8, 12.+" "check array bb after the above change"
+ 
+ gdb_test "step" ".*This is in the subroutine.*" "step into subroutine sub"
+ gdb_test "print *a" ".*5 = .*1, 2, 3, 2, 4, 32, 3, 6, 9, 4, 8, 12.*" "print one-dimension array a"


Regards
- Wu Zhou

Re: [RFC]: Testcase for gdb's handling of Fortran's column-first array

[David Lecomber]

> OK.  With all these said, here is the patch.  I had tested it on FC4, it 
> reported no failure.  But however I _did_ found a old gdb (6.1 maybe) 
> handle this incorrectly.  So this testcase still make senses.  OK to 
> commit?


Hi Wu

That's what I'd expect, as my patch to fix things went in to GDB 6.2.1
(iirc).  

One thing to note is that g77 puts things the wrong way round in the
symbol table (but not in the real data).  In the dwarf2 reader we have
an explicit fix for this incorrect GNU behaviour, but you will not find
the same fix in stabs or dwarf1 -- so on legacy platforms (AIX, Solaris)
with g77 you should expect failure with GNU, pass with IBM's XLF and
Sun's Forte.  

It's also going to fail on Linux with -gstabs as a parameter for g77.  

I've not checked gfortran behaviour -- if it works, it's either because
gfortran haven't fixed the original issue, or they changed the
expression that we check the 'producer' against before making the swap
round (you'll find that in dwarf2readc).

Cheers
d.
-- 
David Lecomber <david@lecomber.net>

Re: [RFC]: Testcase for gdb's handling of Fortran's column-first array

[Wu Zhou]

On Wed, 2 Nov 2005, Jim Blandy wrote:

> 
> David Lecomber <david@lecomber.net> writes:
> > I've not checked gfortran behaviour -- if it works, it's either because
> > gfortran haven't fixed the original issue, or they changed the
> > expression that we check the 'producer' against before making the swap
> > round (you'll find that in dwarf2readc).
> 
> It's worth pointing out that, if the type includes an explicit
> DW_AT_ordering attribute, GDB uses that, and doesn't check the
> producer string at all.  So if g77 gets fixed, they could avoid
> running afoul of the "GNU F77" check simply by making their ordering
> explicit.

I just noticed that there is an attribute for array index ordering.  It 
is very good IMO.  But AFAIK, the g77 is not in active development 
nowadays.  So maybe we can suggest that gfortran developers adopt this so 
that gdb could handle it more gracefully.

GFortran developers,

Would anyone of you feel like adding this attribute into your dwarf 
output?  It is much convenient for gdb to handle the index ordering of 
Fortran arrays.

> 
> This is still a bit of a kludge: the Dwarf spec says that, in the
> absence of an ordering attribute, the ordering is the default for the
> language.  So an explicit "column major" attribute in a Fortran
> compilation unit would be redundant.  I only mention it as a way for
> G77 to avoid breaking old GDB's.
> 


Regards
- Wu Zhou

Re: [RFC]: Testcase for gdb's handling of Fortran's column-first array

[Wu Zhou]

Hi David,

On Wed, 2 Nov 2005, David Lecomber wrote:

> 
> > OK.  With all these said, here is the patch.  I had tested it on FC4, it 
> > reported no failure.  But however I _did_ found a old gdb (6.1 maybe) 
> > handle this incorrectly.  So this testcase still make senses.  OK to 
> > commit?
> 
> 
> Hi Wu
> 
> That's what I'd expect, as my patch to fix things went in to GDB 6.2.1
> (iirc).

Yes. I see you committed a patch for this in 2004-08-29.  So your patch is 
far far before this testcase.  :-)
  
> 
> One thing to note is that g77 puts things the wrong way round in the
> symbol table (but not in the real data).  In the dwarf2 reader we have
> an explicit fix for this incorrect GNU behaviour, but you will not find
> the same fix in stabs or dwarf1 -- so on legacy platforms (AIX, Solaris)
> with g77 you should expect failure with GNU, pass with IBM's XLF and
> Sun's Forte.  
> 
> It's also going to fail on Linux with -gstabs as a parameter for g77.  

I am not familar with stabs format and also don't have AIX or Solaris at 
hand to try any test.  But I found it is okay with "-gstabs" option.  
Don't know why, maybe someone's patch fixed this quietly at some time we 
don't know.  Here is the session snapshot:

woodzltc@linux:~/DE/gdb_cvs/src/gdb/testsuite/gdb.fortran> g77 -gstabs -o dim-order-stabs dim-order.f
woodzltc@linux:~/DE/gdb_cvs/src/gdb/testsuite/gdb.fortran> ~/DE/gdb_cvs/build/gdb/gdb -q ./dim-order-stabs
Using host libthread_db library "/lib/tls/libthread_db.so.1".
(gdb) b dim-order.f :36
Breakpoint 1 at 0x804878b: file dim-order.f, line 36.
(gdb) r
Starting program: 
/home/woodzltc/DE/gdb_cvs/src/gdb/testsuite/gdb.fortran/dim-order-stabs

Breakpoint 1, MAIN__ () at dim-order.f:36
36            call sub(aa)
Current language:  auto; currently fortran
(gdb) p aa
$1 = (( 1, 2, 3) ( 2, 4, 6) ( 3, 6, 9) ( 4, 8, 12) )
(gdb) p aa(3,2)
$2 = 6 


> I've not checked gfortran behaviour -- if it works, it's either because
> gfortran haven't fixed the original issue, or they changed the
> expression that we check the 'producer' against before making the swap
> round (you'll find that in dwarf2readc).

gfortran has some other problem with the multi-dimension array in dwarf 
output.  One of it is that it flatten multi-dimension arrays int one 
dimension ones.  So this testcase doesn't work for gfortran at this time.

P.S: I opened a PR for this behaviour, here is the link: 
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22244

One of gfortran maintainner also open a meta-bug for all debugging related 
problems for gfortran, it is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24546


Regards
- Wu Zhou

[Patch ping]: Testcase for gdb's handling of Fortran's column-first array

[Wu Zhou]

Hello maintainers,

Any idea on this testcase?  Is it worthwhile for it to get into GDB 
testsuite?  Maybe in the incoming 6.4 release? Any comments and 
suggestions are highly appreciated!  Thanks.

Regards
- Wu Zhou

P.S: the original patch link is:

http://sources.redhat.com/ml/gdb-patches/2005-11/msg00056.html

On Thu, 3 Nov 2005, Wu Zhou wrote:

> Hi David,
> 
> On Wed, 2 Nov 2005, David Lecomber wrote:
> 
> > 
> > > OK.  With all these said, here is the patch.  I had tested it on FC4, it 
> > > reported no failure.  But however I _did_ found a old gdb (6.1 maybe) 
> > > handle this incorrectly.  So this testcase still make senses.  OK to 
> > > commit?
> > 
> > 
> > Hi Wu
> > 
> > That's what I'd expect, as my patch to fix things went in to GDB 6.2.1
> > (iirc).
> 
> Yes. I see you committed a patch for this in 2004-08-29.  So your patch is 
> far far before this testcase.  :-)
>   
> > 
> > One thing to note is that g77 puts things the wrong way round in the
> > symbol table (but not in the real data).  In the dwarf2 reader we have
> > an explicit fix for this incorrect GNU behaviour, but you will not find
> > the same fix in stabs or dwarf1 -- so on legacy platforms (AIX, Solaris)
> > with g77 you should expect failure with GNU, pass with IBM's XLF and
> > Sun's Forte.  
> > 
> > It's also going to fail on Linux with -gstabs as a parameter for g77.  
> 
> I am not familar with stabs format and also don't have AIX or Solaris at 
> hand to try any test.  But I found it is okay with "-gstabs" option.  
> Don't know why, maybe someone's patch fixed this quietly at some time we 
> don't know.  Here is the session snapshot:
> 
> woodzltc@linux:~/DE/gdb_cvs/src/gdb/testsuite/gdb.fortran> g77 -gstabs -o dim-order-stabs dim-order.f
> woodzltc@linux:~/DE/gdb_cvs/src/gdb/testsuite/gdb.fortran> ~/DE/gdb_cvs/build/gdb/gdb -q ./dim-order-stabs
> Using host libthread_db library "/lib/tls/libthread_db.so.1".
> (gdb) b dim-order.f :36
> Breakpoint 1 at 0x804878b: file dim-order.f, line 36.
> (gdb) r
> Starting program: 
> /home/woodzltc/DE/gdb_cvs/src/gdb/testsuite/gdb.fortran/dim-order-stabs
> 
> Breakpoint 1, MAIN__ () at dim-order.f:36
> 36            call sub(aa)
> Current language:  auto; currently fortran
> (gdb) p aa
> $1 = (( 1, 2, 3) ( 2, 4, 6) ( 3, 6, 9) ( 4, 8, 12) )
> (gdb) p aa(3,2)
> $2 = 6 
> 
> 
> > I've not checked gfortran behaviour -- if it works, it's either because
> > gfortran haven't fixed the original issue, or they changed the
> > expression that we check the 'producer' against before making the swap
> > round (you'll find that in dwarf2readc).
> 
> gfortran has some other problem with the multi-dimension array in dwarf 
> output.  One of it is that it flatten multi-dimension arrays int one 
> dimension ones.  So this testcase doesn't work for gfortran at this time.
> 
> P.S: I opened a PR for this behaviour, here is the link: 
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=22244
> 
> One of gfortran maintainner also open a meta-bug for all debugging related 
> problems for gfortran, it is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=24546
> 
> 
> Regards
> - Wu Zhou
> 
>