From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 32737 invoked by alias); 14 Nov 2005 03:56:53 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 32722 invoked by uid 22791); 14 Nov 2005 03:56:51 -0000 Received: from ausmtp02.au.ibm.com (HELO ausmtp02.au.ibm.com) (202.81.18.187) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Mon, 14 Nov 2005 03:56:51 +0000 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp02.au.ibm.com (8.12.10/8.12.10) with ESMTP id jAE3ocBt115904 for ; Mon, 14 Nov 2005 14:50:42 +1100 Received: from d23av01.au.ibm.com (d23av01.au.ibm.com [9.190.250.242]) by sd0208e0.au.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id jAE3xdOB044836 for ; Mon, 14 Nov 2005 14:59:40 +1100 Received: from d23av01.au.ibm.com (loopback [127.0.0.1]) by d23av01.au.ibm.com (8.12.11/8.13.3) with ESMTP id jAE3uadF003103 for ; Mon, 14 Nov 2005 14:56:37 +1100 Received: from [9.181.133.252] ([9.181.133.252]) by d23av01.au.ibm.com (8.12.11/8.12.11) with ESMTP id jAE3uYJJ003047; Mon, 14 Nov 2005 14:56:35 +1100 Date: Mon, 14 Nov 2005 10:08:00 -0000 From: Wu Zhou To: David Lecomber cc: jimb@red-bean.com, drow@false.org, gdb-patches@sources.redhat.com Subject: [Patch ping]: Testcase for gdb's handling of Fortran's column-first array In-Reply-To: Message-ID: References: <1130918595.9928.22.camel@cpc2-oxfd8-3-0-cust199.oxfd.cable.ntl.com> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2005-11/txt/msg00185.txt.bz2 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 > >