Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
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;
 }

             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