From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22524 invoked by alias); 3 Nov 2005 10:16:34 -0000 Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org Received: (qmail 22516 invoked by uid 22791); 3 Nov 2005 10:16:32 -0000 Received: from ausmtp01.au.ibm.com (HELO ausmtp01.au.ibm.com) (202.81.18.186) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 03 Nov 2005 10:16:32 +0000 Received: from sd0208e0.au.ibm.com (d23rh904.au.ibm.com [202.81.18.202]) by ausmtp01.au.ibm.com (8.12.10/8.12.10) with ESMTP id jA3AJcug141908 for ; Thu, 3 Nov 2005 21:19:38 +1100 Received: from d23av03.au.ibm.com (d23av03.au.ibm.com [9.190.250.244]) by sd0208e0.au.ibm.com (8.12.10/NCO/VERS6.7) with ESMTP id jA3AJOGE074506 for ; Thu, 3 Nov 2005 21:19:26 +1100 Received: from d23av03.au.ibm.com (loopback [127.0.0.1]) by d23av03.au.ibm.com (8.12.11/8.13.3) with ESMTP id jA3AGKjO002517 for ; Thu, 3 Nov 2005 21:16:21 +1100 Received: from [9.181.133.252] ([9.181.133.252]) by d23av03.au.ibm.com (8.12.11/8.12.11) with ESMTP id jA3AGIIF002449; Thu, 3 Nov 2005 21:16:19 +1100 Date: Thu, 03 Nov 2005 10:16:00 -0000 From: Wu Zhou To: Jim Blandy cc: Mark Kettenis , gdb@sources.redhat.com Subject: Re: The root cause for SEGV in evaluating fortran function call, any solution or suggestion? In-Reply-To: Message-ID: References: <200511021551.jA2FpO7D009728@elgar.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2005-11/txt/msg00057.txt.bz2 On Wed, 2 Nov 2005, Jim Blandy wrote: > > Mark Kettenis writes: > > One could argue that the debug information generated by g77 is wrong, > > because it doesn't reflect the actual implementation of FUNC_NAME. Or > > perhaps GDB symbol reading code causes problems. Can you post a > > concrete example of a function call that goes wrong, and add a bit of > > explanation about the types involved for those of us who are not very > > familiar with Fortran? > > The types in the debug information should not reflect the extra level > of indirection; the fact that they're passed by reference is just part > of the meaning of a Fortran function call. But the location > expression should encode the extra level of indirection. > > Probably value_arg_coerce should be a language method. The C > promotion rules aren't appropriate for Fortran anyway, and the Fortran > version could take care of applying value_addr (or something like > that), and turning the array of actuals into an array of pointers to > the actuals. Jim, it seems that you just said out what I am thinking of. Function value_arg_coerce is said to perform the standard coercion that are specified for arguments to be passed to C functions (you can see that in the comment). But it is also used for Fortran functions (maybe all other function GDB supports). What is more, I find that when I pass "res_(b)" to gfortran code in gdb command line, it will get the correct result. All the difference is that gfortran handle the parameters as reference to the actuals. So value_arg_coerce will call value_addr to convert args into the address of them, so we can get the correct result. However with gfortran, "print res_(2)" still doesn't get the correct result. But it fail more gracefully, it reports the following error message: Attempt to take address of value not located in memory. Which is well expected with reference to the code in value_arg_coerce. So I am thinking of a somwhat different value_arg_coerce for Fortran code: when the parameter type is a reference (for gfortran) or pointer (for g77), we can call something like value_addr to changed the argument into its address. I did some tests today, but no success so far. Will take some more look into this. Any suggestion, comments on this? Thanks! Regards - Wu Zhou