This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA/sparc] pb doing next over struct-return function
- From: Mark Kettenis <kettenis at gnu dot org>
- To: brobecker at adacore dot com
- Cc: gdb-patches at sources dot redhat dot com
- Date: Tue, 23 Nov 2004 09:33:06 +0100 (CET)
- Subject: Re: [RFA/sparc] pb doing next over struct-return function
- References: <20041123053544.GM1141@adacore.com>
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