From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22437 invoked by alias); 7 Jun 2005 09:03:08 -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 22403 invoked by uid 22791); 7 Jun 2005 09:03:01 -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; Tue, 07 Jun 2005 09:03:01 +0000 Received: from sd0112e0.au.ibm.com (d23rh903.au.ibm.com [202.81.18.201]) by ausmtp02.au.ibm.com (8.12.10/8.12.10) with ESMTP id j578wKZX382164 for ; Tue, 7 Jun 2005 18:58:21 +1000 Received: from d23av04.au.ibm.com (d23av04.au.ibm.com [9.190.250.237]) by sd0112e0.au.ibm.com (8.12.10/NCO/VER6.6) with ESMTP id j5795RDs093202 for ; Tue, 7 Jun 2005 19:05:27 +1000 Received: from d23av04.au.ibm.com (loopback [127.0.0.1]) by d23av04.au.ibm.com (8.12.11/8.13.3) with ESMTP id j5792W2x003209 for ; Tue, 7 Jun 2005 19:02:32 +1000 Received: from plinuxt18.cn.ibm.com (plinuxt18.cn.ibm.com [9.181.140.28]) by d23av04.au.ibm.com (8.12.11/8.12.11) with ESMTP id j5792UkV003135 for ; Tue, 7 Jun 2005 19:02:31 +1000 Date: Tue, 07 Jun 2005 09:03:00 -0000 From: Wu Zhou To: gdb@sources.redhat.com Subject: Re: Program terminated with SIGSEGV when trying to print an array element In-Reply-To: Message-ID: References: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2005-06/txt/msg00058.txt.bz2 On Tue, 7 Jun 2005, Wu Zhou wrote: > (gdb) p a(1) > > Program terminated with signal SIGSEGV, Segmentation fault. > The program no longer exists. > The program being debugged stopped while in a function called from GDB. > When the function (at 0xbf8b9b50) is done executing, GDB will silently > stop (instead of continuing to evaluate the expression containing > the function call). I am doing some debugging on this. It seems that GDB take a(1) as a function. But in fact that function doesn't exist at all. The related code is in function evaluate_subexp_standard (in eval.c). The opcode of "a(1)" is OP_F77_UNDETERMINED_ARGLIST at the parse time, and its real type need to be determined at run time: case OP_F77_UNDETERMINED_ARGLIST: /* Remember that in F77, functions, substring ops and array subscript operations cannot be disambiguated at parse time. We have made all array subscript operations, substring operations as well as function calls come here and we now have to discover what the heck this thing actually was. If it is a function, we process just as if we got an OP_FUNCALL. */ nargs = longest_to_int (exp->elts[pc + 1].longconst); (*pos) += 2; /* First determine the type code we are dealing with. */ arg1 = evaluate_subexp (NULL_TYPE, exp, pos, noside); type = check_typedef (value_type (arg1)); code = TYPE_CODE (type); switch (code) { case TYPE_CODE_ARRAY: goto multi_f77_subscript; case TYPE_CODE_STRING: goto op_f77_substr; case TYPE_CODE_PTR: case TYPE_CODE_FUNC: /* It's a function call. */ /* Allocate arg vector, including space for the function to be called in argvec[0] and a terminating NULL */ argvec = (struct value **) alloca (sizeof (struct value *) * (nargs + 2)); argvec[0] = arg1; tem = 1; for (; tem <= nargs; tem++) argvec[tem] = evaluate_subexp_with_coercion (exp, pos, noside); 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! Cheers - Wu Zhou