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
next prev parent 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