This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Program terminated with SIGSEGV when trying to print an arrayelement
- From: Wu Zhou <woodzltc at cn dot ibm dot com>
- To: gdb at sources dot redhat dot com
- Date: Tue, 7 Jun 2005 16:58:10 +0800 (CST)
- Subject: Re: Program terminated with SIGSEGV when trying to print an arrayelement
- References: <Pine.LNX.4.63.0506071550050.28024@plinuxt18.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