From: Mark Kettenis <kettenis@gnu.org>
To: brobecker@adacore.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA/sparc] pb doing next over struct-return function
Date: Tue, 23 Nov 2004 08:33:00 -0000 [thread overview]
Message-ID: <200411230833.iAN8X6Ru027549@juw15.nfra.nl> (raw)
In-Reply-To: <20041123053544.GM1141@adacore.com> (message from Joel Brobecker on Mon, 22 Nov 2004 21:35:44 -0800)
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
next prev parent reply other threads:[~2004-11-23 8:33 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-23 5:35 Joel Brobecker
2004-11-23 8:33 ` Mark Kettenis [this message]
2004-11-23 11:33 ` Eli Zaretskii
2004-11-23 12:06 ` Richard Earnshaw
2004-11-23 19:57 ` Paul Hilfinger
2004-11-23 19:29 ` Joel Brobecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200411230833.iAN8X6Ru027549@juw15.nfra.nl \
--to=kettenis@gnu.org \
--cc=brobecker@adacore.com \
--cc=gdb-patches@sources.redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox