[RFA/RFC/sparc32] SIGSEGV during fun call when no debugging info

[Joel Brobecker <brobecker at adacore dot com>]

Hello

Looks like we're no longer able to call functions on sparc target
when the function hasn't been compiled with debugging information.
I noticed this because calls to functions taking strings as an argument
were now causing the debugger to crash - but the problem can be reduced
to calling "malloc":

    (gdb) p malloc (1)
    zsh: 21029 segmentation fault (core dumped)  ../gdb-head/gdb/gdb hello

The problem has been introduced during the enhancement for multiple
calling conventions, for which we added an extra argument (the function
type) to the "struct_return" gdbarch method.  The sparc-tdep.c code
was then changed as follow:

    -  if (using_struct_return (value_type))
    +  if (using_struct_return (SYMBOL_TYPE (find_pc_function (funcaddr)),
    +                          value_type))

Because "malloc" hasn't been compiled with debugging info, find_pc_function
return NULL, and so SYMBOL_TYPE causes a SEGV.

One approach would be to enhance the code above to also handle function
calls when no symbol is found. This is what find_function_in_inferior
does, and we could do something similar.  But seems a bit absurd to do
that, because we don't have multiple calling conventions on sparc.
So finding the type would be useless.

Following on the last observation, another way of fixing the problem
would be to simply pass NULL as the function type to using_struct_return,
since we don't need to check the function type to do what we need
to do in this case.

One final approach is to change the code in sparc32_push_dummy_code
to call sparc32_return_value directly, instead of going through
using_struct_return. That was more appealing that computing the
function type, but that hard code the assumption that the return_value
gdbarch method is in fact sparc32_return_value, and also re-introduces
a new instance of "current_gdbarch".

I think the best way to go in this case is option 2, which is to accept
NULL as the function type, and document that fact.  This is what my 
patch does.

I checked Corinna's patch (which introduced this extra parameter),
and there are only 2 instances that really use that new parameter,
both in sh-tdep.c: sh_return_value_nofpu and sh_return_value_fpu.
They already both handle the case when the function type is NULL
by defaulting to the user-setting "set sh calling-convention".

2008-04-29  Joel Brobecker  <brobecker@adacore.com>

	* gdbarch.sh: Document the return_value method. Explain that
	the FUNCTYPE parameter might be NULL.
	* gdbarch.h: Regenerated.
	* sparc-tdep.c (sparc32_push_dummy_code): Do not pass the function
	type when calling using_struct_return, as this is unnecessary
	on this target.

Tested on sparc-solaris. Fixes many many regressions in gdb.ada,
gdb.base and gdb.gdb.

OK to apply?

Thanks,
-- 
Joel

Attachment: struct_return.diff
Description: Text document