Re: [RFA/sparc] pb doing next over struct-return function

[Joel Brobecker <brobecker@adacore.com>]

>    Digging deeper, I found that this address is incorrectly computed
>    because cache->struct_return_p in sparc32_frame_cache() is not
>    set. And the reason for it not being set is that there is no
>    debugging information available for system__img_int__image_integer,
>    because it is part of the GNAT runtime, which is compiled without
>    debugging information.
> 
> Just an aside, is there anything against shipping/compiling the GNAT
> runtime with debug information?

Yes. One of the reasons is size of debugging information. With Ada,
it's pretty large.

>    2004-11-22  Joel Brobecker  <brobecker@gnat.com>
> 
> 	   * sparc-tdep.c (is_unimp_insn): New function.
> 	   (sparc32_frame_cache): For functions where there is no debugging
> 	   information to help us determine whether it's a struct-return
> 	   function or not, fallback on checking whether the instruction
> 	   at the return address is a "unimp" instruction or not.
> 
> Makes sense to me.  Could you do me a favour and rename the function
> to sparc_unimp_insn_p?  If you feel like it you may move it to just
> after sparc_fetch_instruction, which seems a somwhat more logical
> place to me (but only slightly so).  Please also fix a few
> spelling-mistakes in comments:

Thanks. Checked in with the changes you requested (renaming the new
function, moving it up, and making the spelling corrections).

Although ``a "unimp" instruction" seem more natural to me, I did
follow your recommendation. It's easy to change it back if it turns
out one day that the use of "a" in this case is more common than
the use of "an".

Thanks,
-- 
Joel