From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-23139-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 25239 invoked by alias); 10 Nov 2005 00:49:18 -0000
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
Received: (qmail 25228 invoked by uid 22791); 10 Nov 2005 00:49:15 -0000
Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31)
    by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Thu, 10 Nov 2005 00:49:15 +0000
Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254])
	by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id jAA0nD0Z012815
	for <gdb@sources.redhat.com>; Wed, 9 Nov 2005 19:49:13 -0500
Received: from pobox.corp.redhat.com (pobox.corp.redhat.com [172.16.52.156])
	by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id jAA0nDV17270;
	Wed, 9 Nov 2005 19:49:13 -0500
Received: from theseus.home..redhat.com (vpn26-3.sfbay.redhat.com [172.16.26.3])
	by pobox.corp.redhat.com (8.12.8/8.12.8) with ESMTP id jAA0nAkl026073;
	Wed, 9 Nov 2005 19:49:10 -0500
To: Mark Kettenis <mark.kettenis@xs4all.nl>
Cc: woodzltc@cn.ibm.com, gdb@sources.redhat.com, fortran@gcc.gnu.org
Subject: Re: The root cause for SEGV in evaluating fortran function call, any solution or suggestion?
References: <Pine.LNX.4.63.0508221743470.10411@linux.site>
	<Pine.LNX.4.63.0511021033530.3549@linux.site>
	<200511021551.jA2FpO7D009728@elgar.sibelius.xs4all.nl>
	<vt2oe52npn7.fsf@theseus.home.>
	<20051107000229.GC19200@nevyn.them.org>
From: Jim Blandy <jimb@redhat.com>
Date: Thu, 10 Nov 2005 00:49:00 -0000
In-Reply-To: <20051107000229.GC19200@nevyn.them.org> (Daniel Jacobowitz's message of "Sun, 6 Nov 2005 19:02:29 -0500")
Message-ID: <vt2slu58gze.fsf@theseus.home.>
User-Agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
X-SW-Source: 2005-11/txt/msg00209.txt.bz2


Daniel Jacobowitz <drow@false.org> writes:
> On Wed, Nov 02, 2005 at 11:42:36PM -0800, Jim Blandy wrote:
>> 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.
>
> This seems perfectly sensible to me.  But the example Wu posted earlier
> does not agree: today gfortran apparently puts out the indirections
> explicitly.

You're talking about this, where 'm' is declared as 'integer', right?

 <1><da>: Abbrev Number: 7 (DW_TAG_subprogram)
     DW_AT_sibling     : <10f>
     DW_AT_external    : 1
     DW_AT_name        : res_
     DW_AT_decl_file   : 1
     DW_AT_decl_line   : 23
     DW_AT_type        : <bb>
     DW_AT_low_pc      : 0x804863f
     DW_AT_high_pc     : 0x8048655
     DW_AT_frame_base  : 1 byte block: 55       (DW_OP_reg5)
 <2><f5>: Abbrev Number: 8 (DW_TAG_formal_parameter)
     DW_AT_name        : m
     DW_AT_type        : <10f>   =====> This is a const pointer to integer
     DW_AT_artificial  : 1
     DW_AT_location    : 2 byte block: 91 8     (DW_OP_fbreg: 8)

 <1><10f>: Abbrev Number: 9 (DW_TAG_const_type)
     DW_AT_type        : <114>
 <1><114>: Abbrev Number: 10 (DW_TAG_pointer_type)
     DW_AT_byte_size   : 4
     DW_AT_type        : <bb>
 <1><bb>: Abbrev Number: 6 (DW_TAG_base_type)
     DW_AT_name        : integer
     DW_AT_byte_size   : 4
     DW_AT_encoding    : 5      (signed)

> So it sounds like gfortran will need to be fixed.

Yep.  The types in the Dwarf information should match the types as
they appear in the source language.