From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7718 invoked by alias); 7 Jun 2005 13:14:25 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 7706 invoked by uid 22791); 7 Jun 2005 13:14:20 -0000 Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 07 Jun 2005 13:14:20 +0000 Received: from drow by nevyn.them.org with local (Exim 4.50) id 1DfduL-0007v7-SH; Tue, 07 Jun 2005 09:14:18 -0400 Date: Tue, 07 Jun 2005 13:14:00 -0000 From: Daniel Jacobowitz To: Wu Zhou Cc: gdb@sources.redhat.com Subject: Re: Program terminated with SIGSEGV when trying to print an array element Message-ID: <20050607131417.GB30174@nevyn.them.org> Mail-Followup-To: Wu Zhou , gdb@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-06/txt/msg00061.txt.bz2 On Tue, Jun 07, 2005 at 04:58:10PM +0800, Wu Zhou wrote: > As far as I can see, the problem lies in that GDB take TYPE_CODE_PTR as > a function call as well. But in the above failing testcase, "a" is a > pointer to array type (Fortran treat formal parameter as pointer). Its > code is TYPE_CODE_PTR indeed, but it is not a function call. > > So maybe we need to change the code logic above. My thought is when the > code match TYPE_CODE_PTR, we first get its target_type. If it is > TYPE_CODE_ARRAY, we can goto multi_f77_subscript. If not, we can go on > with the orignial path. But I have one question on the original code: > in which circumstance should a function's code return TYPE_CODE_PTR, > isn't the code of a function always return TYPE_CODE_FUNC? > > Any thought on this? Any suggestions and comments are highly appreciated! You didn't mention what Fortran compiler was being used. Probably, whichever one it was, it generates debug information that GDB is not expecting. It sounds like you're right; we should be checking the target type of the pointer. Can we end up with a pointer to a string, too? I'm afraid I don't know the answer to your other question. -- Daniel Jacobowitz CodeSourcery, LLC