Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Mark Kettenis <mark.kettenis@xs4all.nl>
To: roland.schwingel@onevision.de
Cc: gdb@sourceware.org
Subject: Re: gdb stack trace problems (Addendum)
Date: Mon, 25 Apr 2005 19:35:00 -0000	[thread overview]
Message-ID: <200504251926.j3PJQWUS002190@elgar.sibelius.xs4all.nl> (raw)
In-Reply-To: <426CA356.60901@onevision.de> (message from Roland Schwingel on Mon, 25 Apr 2005 09:59:18 +0200)

   Date: Mon, 25 Apr 2005 09:59:18 +0200
   From: Roland Schwingel <roland.schwingel@onevision.de>

    > Anyway, there is a serious problem here.  The code you show is
    > basically undebuggable.
    > [...]
    > The only thing we can do here is trust the frame pointer, like we used
    > to do in the old days.  The problem with that is that it's very likely
    > to (silently) skip some function calls.  In your particular example it
    > probably would appear as if your code called SleepEx directly and
    > there would be no trace of Sleep at all.  That can be quite puzzling.
    >
    > I'm thinking about adding an option to instruct gdb to "trust" the
    > frame pointer.  I'm not going to make it the default though.  I really
    > prefer seeing an abviously wrong backtrace over gdb silently skipping
    > function calls in its backtraces.
   Well the present situation is quite problematic for us. In past days 
   (gdb 5.3)
   when an application crashed we had a quite accurate backtrace. It wasn't
   wrong (for us). Finding/Fixing bugs was very easy. GDB has been
   very useful here.

You probably didn't notice it was wrong...

   With gdb 6.x we are no longer able to get a backtrace in these
   cases (in about 95% of all cases). This is a serious problem and
   makes gdb 6.x quite unusable for us (and maybe others on
   windows). Having at least an option for enabling that feature would
   be IMHO absolutely necessary. I wonder why other users on windows
   haven't complained earlier about this problem.

Oh they've complained, but never followed through when I asked for
information or tests.

   So will you implement such an option? I am quite unfamiliar with
   the internals of gdb's stack unwinding, so I am not of much help
   here. But whenever I can do something to help to fix this I am
   happily volunteering to do so.

Can you test the attached patch?  It introduces a new option named
"trust-frame-pointer".  Whenever you encounter a problem you can:

(gdb) set trust-frame-pointer 1

and try again.  You probably want to reset it to 0 before continuing
your program since I found out that bad things happen with some of the
tests in the gdb testsuite with this turned on.

Mark


Index: i386-tdep.c
===================================================================
RCS file: /cvs/src/src/gdb/i386-tdep.c,v
retrieving revision 1.209
diff -u -p -r1.209 i386-tdep.c
--- i386-tdep.c 6 Apr 2005 17:01:25 -0000 1.209
+++ i386-tdep.c 25 Apr 2005 19:24:54 -0000
@@ -858,10 +858,19 @@ i386_unwind_pc (struct gdbarch *gdbarch,
 
 /* Normal frames.  */
 
+static int trust_frame_pointer = 0;
+
+static void set_trust_frame_pointer (char *args, int from_tty,
+				     struct cmd_list_element *c)
+{
+  flush_cached_frames();
+}
+
 static struct i386_frame_cache *
 i386_frame_cache (struct frame_info *next_frame, void **this_cache)
 {
   struct i386_frame_cache *cache;
+  CORE_ADDR pc = 0;
   char buf[4];
   int i;
 
@@ -890,7 +899,8 @@ i386_frame_cache (struct frame_info *nex
 
   cache->pc = frame_func_unwind (next_frame);
   if (cache->pc != 0)
-    i386_analyze_prologue (cache->pc, frame_pc_unwind (next_frame), cache);
+    pc = i386_analyze_prologue (cache->pc, frame_pc_unwind (next_frame),
+				cache);
 
   if (cache->locals < 0)
     {
@@ -902,8 +912,11 @@ i386_frame_cache (struct frame_info *nex
 	 frame by looking at the stack pointer.  For truly "frameless"
 	 functions this might work too.  */
 
-      frame_unwind_register (next_frame, I386_ESP_REGNUM, buf);
-      cache->base = extract_unsigned_integer (buf, 4) + cache->sp_offset;
+      if (!trust_frame_pointer || pc == frame_pc_unwind (next_frame))
+	{
+	  frame_unwind_register (next_frame, I386_ESP_REGNUM, buf);
+	  cache->base = extract_unsigned_integer (buf, 4) + cache->sp_offset;
+	}
     }
 
   /* Now that we have the base address for the stack frame we can
@@ -2360,6 +2373,16 @@ is \"default\"."),
 			NULL, /* FIXME: i18n: */
 			&setlist, &showlist);
 
+  /* Add the variable that controls whether we trust the frame pointer.  */
+  add_setshow_boolean_cmd ("trust-frame-pointer", no_class,
+			   &trust_frame_pointer, _("\
+Set whether we trust the frame pointer"), _("\
+Show whether we trust the frame pointer"), _("\
+XXXX"),
+			   set_trust_frame_pointer,
+			   NULL, /* FIXME: i18n: */
+			   &setlist, &showlist);
+
   gdbarch_register_osabi_sniffer (bfd_arch_i386, bfd_target_coff_flavour,
 				  i386_coff_osabi_sniffer);
   gdbarch_register_osabi_sniffer (bfd_arch_i386, bfd_target_nlm_flavour,


  parent reply	other threads:[~2005-04-25 19:28 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2005-04-25 12:35 Roland Schwingel
2005-04-25  8:00 ` Roland Schwingel
2005-04-25 19:35 ` Mark Kettenis [this message]
2005-04-25 19:45   ` Daniel Jacobowitz
2005-04-25 20:37     ` Mark Kettenis
  -- strict thread matches above, loose matches on Subject: below --
2005-05-10  8:39 Roland Schwingel
2005-05-10  8:38 Roland Schwingel
2005-05-02  7:04 Roland Schwingel
2005-05-08 13:31 ` Mark Kettenis
2005-05-08 23:20   ` Christopher Faylor
2005-05-09  4:48     ` Eli Zaretskii
2005-05-09  5:26       ` Christopher Faylor
2005-05-09  5:30     ` Stan Shebs
2005-04-26 11:53 Roland Schwingel
2005-04-26  9:11 Roland Schwingel
2005-04-19  8:01 Roland Schwingel
     [not found] ` <4268B942.5080300@onevision.de>
2005-04-22 17:51   ` Mark Kettenis
2005-04-19  7:34 Roland Schwingel
2005-04-19  7:45 ` Mark Kettenis

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=200504251926.j3PJQWUS002190@elgar.sibelius.xs4all.nl \
    --to=mark.kettenis@xs4all.nl \
    --cc=gdb@sourceware.org \
    --cc=roland.schwingel@onevision.de \
    /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