From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sources.redhat.com
Subject: [RFA/sparc] pb doing next over struct-return function
Date: Tue, 23 Nov 2004 05:35:00 -0000 [thread overview]
Message-ID: <20041123053544.GM1141@adacore.com> (raw)
[-- Attachment #1: Type: text/plain, Size: 2857 bytes --]
Hello,
This is on sparc - solaris 2.8:
Consider the following code:
with Ada.Text_IO; use Ada.Text_IO;
procedure Small is
I : Integer := 123;
begin
Put_Line (Integer'Image(I)); -- line 6
I := I + 1;
end Small;
Compile it with:
% gnatmake -g small
And then try to to a next over line 6:
% gdb small
(gdb) b small.adb:6
(gdb) run
Starting program: /[...]/small
Breakpoint 1, small () at small.adb:6
6 Put_Line (Integer'Image(I));
(gdb) n
123
Program exited normally.
Ooops, the debugger doesn't stop at line 7! Here is why:
First of all, Integer'Image is a call to a function which transforms
the Integer variable I into a string. The actually name of the function
is: system__img_int__image_integer.
When GDB does the stepping, it eventually lands inside that function.
Finds out that it has stepped inside it by comparing the frame ID of
the previous frame against the step_frame_id, and therefore puts a
breakpoint at the return address and resumes the execution.
Unfortunately, the breakpoint breakpoint location chosen is not
correct, it's one instruction too early, and that causes the breakpoint
to never be hit. Hence the "Program exited normally".
The reason for the incorrect breakpoint location is that GDB
does not see that system__img_int__image_integer is a struct-return
function. So the address pointed by "saved_pc + 8" is a "unimp"
instruction, which of course is never executed unless something
is badly wrong.
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.
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.
Tested on sparc-solaris. Ok to commit?
Thanks,
--
Joel
[-- Attachment #2: sparc-tdep.c.diff --]
[-- Type: text/plain, Size: 1460 bytes --]
Index: sparc-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/sparc-tdep.c,v
retrieving revision 1.156
diff -u -p -r1.156 sparc-tdep.c
--- sparc-tdep.c 21 Nov 2004 20:11:09 -0000 1.156
+++ sparc-tdep.c 23 Nov 2004 05:01:15 -0000
@@ -640,6 +640,17 @@ sparc_frame_cache (struct frame_info *ne
return cache;
}
+/* Return True if the instruction corresponding to PC is a "unimp"
+ instruction. */
+
+static int
+is_unimp_insn (CORE_ADDR pc)
+{
+ const unsigned long insn = sparc_fetch_instruction (pc);
+
+ return ((insn & 0xc1c00000) == 0);
+}
+
struct sparc_frame_cache *
sparc32_frame_cache (struct frame_info *next_frame, void **this_cache)
{
@@ -665,6 +676,21 @@ sparc32_frame_cache (struct frame_info *
cache->struct_return_p = 1;
}
}
+ 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. */
+ CORE_ADDR pc;
+ int regnum = cache->frameless_p ? SPARC_O7_REGNUM : SPARC_I7_REGNUM;
+
+ pc = frame_unwind_register_unsigned (next_frame, regnum) + 8;
+ if (is_unimp_insn (pc))
+ cache->struct_return_p = 1;
+ }
return cache;
}
next reply other threads:[~2004-11-23 5:35 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2004-11-23 5:35 Joel Brobecker [this message]
2004-11-23 8:33 ` Mark Kettenis
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=20041123053544.GM1141@adacore.com \
--to=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