Re: Program terminated with SIGSEGV when trying to print an array element

[Wu Zhou <woodzltc@cn.ibm.com>]

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