This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


   Date: Mon, 22 Nov 2004 21:35:44 -0800
   From: 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?

   So I made a small change to sparc32_frame_cache() to fallback to
   a small heuristic that should help determine whether the function
   is a struct-return or not based on the instruction found at
   "saved_pc + 8". If it is a "unimp", then for chances are the
   function won't return there, but one instruction later. And hence,
   we must have a struct-return function.

   This fixes the problem above, and does not introduce any regression
   in the testsuite.

   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:

   +/* Return True if the instruction corresponding to PC is a "unimp"
   +   instruction.  */

Return non-zero if the instruction at PC is an "unimp" instruction.
       ^^^^^^^^                              ^

   +  else
   +    {
   +      /* There is no debugging information for this function to
   +         help us determine whether this function returns a struct
   +         or not.  So we rely on another heuristic which is to check
   +         the instruction at the return address and see if this is
   +         a "unimp" instruction.  If it is, then it is struct-return
   +         function.  */

an "unimp" instruction.  If it is, then it s a struct-return
 ^                                           ^

Thanks,

Mark


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]