Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: Robert Dewar <dewar@adacore.com>,
	Wiljan Derks <Wiljan.Derks@zonnet.nl>,
		gdb@sourceware.org, Mark Kettenis <kettenis@gnu.org>
Subject: Re: How to tell gdb about dlls using remote protocol
Date: Fri, 02 Feb 2007 17:34:00 -0000	[thread overview]
Message-ID: <20070202173456.GT17864@adacore.com> (raw)
In-Reply-To: <20070202165619.GA30801@nevyn.them.org>

[-- Attachment #1: Type: text/plain, Size: 592 bytes --]

> Hmm, perhaps it successfully gets you out and only misses frames.  I'm
> pretty sure I remember that when debugging a Windows build of GDB, the
> select helper threads live somewhere in NTDLL without a valid frame.

I am not sure about that particular thread. But for the other ones,
we are indeed counting on the fact that all we lose is skipping one
frame.

> I'd be curious to see it, at least, but I'm not sure what we can do.

Here it is. The diff is probably malformed, because I had to remove
a couple of patches we backported from head, but that should give
you the idea.

-- 
Joel

[-- Attachment #2: ebp.diff --]
[-- Type: text/plain, Size: 3459 bytes --]

+/* Return non-zero if the function starting at START_PC has a prologue
+   that sets up a standard frame.  */
+
+static int
+i386_function_has_frame (CORE_ADDR start_pc)
+{
+  struct i386_frame_cache cache;
+
+  cache.locals = -1;
+  i386_analyze_prologue (start_pc, 0xffffffff, &cache);
+
+  return (cache.locals >= 0);
+}
+
+/* Return non-zero if PC is inside one of the inferior's DLLs.  */
+
+static int
+i386_in_dll (CORE_ADDR pc)
+{
+   char *so_name = solib_address (pc);
+   int len;
+
+   if (so_name == NULL)
+     return 0;
+
+   len = strlen (so_name);
+   if (len < 5)
+     return 0;
+
+   return ((so_name[len - 1] == 'l' || so_name[len - 1] == 'L')
+           && (so_name[len - 2] == 'l' || so_name[len - 2] == 'L')
+           && (so_name[len - 3] == 'd' || so_name[len - 3] == 'D')
+           && so_name[len - 4] == '.');
+}
+
 /* Normal frames.  */
 
 static struct i386_frame_cache *
@@ -954,20 +1159,49 @@ i386_frame_cache (struct frame_info *nex
 	 frame by looking at the stack pointer.  For truly "frameless"
 	 functions this might work too.  */
 
-      if (cache->stack_align)
-	{
-	  /* We're halfway aligning the stack.  */
-	  cache->base = ((cache->saved_sp - 4) & 0xfffffff0) - 4;
-	  cache->saved_regs[I386_EIP_REGNUM] = cache->saved_sp - 4;
+      if (i386_in_dll (cache->pc)
+          && !i386_function_has_frame (cache->pc))
+        {
+          /* Functions in DLL for which do not seem to create a standard
+             frame are unwound using %ebp.  This is actually the caller's
+             frame base instead of our own, but there are some functions
+             such as WaitForSingleObjectEx in one of the Windows system
+             DLLs for which the frame base cannot possibly be determined
+             from the stack pointer.  As a consequence, our caller will be
+             missing from the backtrace, but this is better than having
+             an aborted backtrace due to a bogus frame base.
+             
+             We use this approach only for functions in DLLs because
+             this is the only place where we have seen the type of
+             highly optimized code that cause us trouble.  In other
+             cases, we expect the code to come with frame debugging
+             information, making prologue scanning unnecessary.
+             
+             We also avoid blindly following %ebp if we are midway through
+             setting up a standard frame.  In that case, we know how to
+             determine the frame base using the stack pointer.  */
 
-	  /* This will be added back below.  */
-	  cache->saved_regs[I386_EIP_REGNUM] -= cache->base;
-	}
+          cache->saved_regs[I386_EBP_REGNUM] = 0;
+        }
       else
-	{
-	  frame_unwind_register (next_frame, I386_ESP_REGNUM, buf);
-	  cache->base = extract_unsigned_integer (buf, 4) + cache->sp_offset;
-	}
+        {
+	  if (cache->stack_align)
+	    {
+	      /* We're halfway aligning the stack.  */
+	      cache->base = ((cache->saved_sp - 4) & 0xfffffff0) - 4;
+	      cache->saved_regs[I386_EIP_REGNUM] = cache->saved_sp - 4;
+
+	      /* This will be added back below.  */
+	      cache->saved_regs[I386_EIP_REGNUM] -= cache->base;
+	    }
+	  else
+	    {
+	      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

  reply	other threads:[~2007-02-02 17:34 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-01-31 21:08 Wiljan Derks
2007-01-31 22:31 ` Daniel Jacobowitz
2007-02-01 17:52   ` Joel Brobecker
2007-02-01 22:54     ` Daniel Jacobowitz
2007-02-01 23:02       ` Joel Brobecker
2007-02-01 23:59         ` Daniel Jacobowitz
2007-02-02  6:20           ` Robert Dewar
2007-02-02 11:43             ` Daniel Jacobowitz
2007-02-02 16:51               ` Joel Brobecker
2007-02-02 16:56                 ` Daniel Jacobowitz
2007-02-02 17:34                   ` Joel Brobecker [this message]
2007-02-05 20:34                     ` Wiljan Derks
2007-02-05 21:21                       ` Joel Brobecker
2007-02-07 21:47                     ` Mark Kettenis
2007-02-07 22:14     ` Mark Kettenis
2007-02-07 22:17       ` Daniel Jacobowitz
2007-02-08 21:14         ` Mark Kettenis
2007-02-08 23:00           ` Daniel Jacobowitz
2007-02-14  8:51             ` 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=20070202173456.GT17864@adacore.com \
    --to=brobecker@adacore.com \
    --cc=Wiljan.Derks@zonnet.nl \
    --cc=dewar@adacore.com \
    --cc=gdb@sourceware.org \
    --cc=kettenis@gnu.org \
    /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