This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Strange stack trace on Windows
- From: Joel Brobecker <brobecker at adacore dot com>
- To: Gordon Prieur <Gordon dot Prieur at Sun dot COM>
- Cc: Eli Zaretskii <eliz at gnu dot org>, gdb at sourceware dot org
- Date: Mon, 1 Oct 2007 07:39:06 -0700
- Subject: Re: Strange stack trace on Windows
- References: <46FEC75E.9010207@Sun.COM> <uk5q8bp8j.fsf@gnu.org> <4700FE1E.6040201@sun.com>
> Sometime yes, sometimes no. I implemented that solution abotu 6 months
> ago but backed it out because it was just as likely to crash gdb:-(
> or hang my IDE (netbeans).
We have experienced the same type of problem at AdaCore, and decided
to make some compromises: We decided to trust the %ebp registers when
unwinding frameless functions from a DLL. This comes with a price:
We miss a frame in the backtrace. But because tasking is so important
in Ada, we felt it was a better compromise than not being able to unwind
from tasks that are blocked waiting for a rendez-vous.
Which compromise is best actually depends on the user, which is why
this code, or a variation of it, never made it to the FSF tree.
This is what our i386_frame_cache() does in case of frameless routines:
if (cache->locals < 0)
{
/* We didn't find a valid frame, which means that CACHE->base
currently holds the frame pointer for our calling frame. If
we're at the start of a function, or somewhere half-way its
prologue, the function's frame probably hasn't been fully
setup yet. Try to reconstruct the base address for the stack
frame by looking at the stack pointer. For truly "frameless"
functions this might work too. */
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. */
cache->saved_regs[I386_EBP_REGNUM] = 0;
}
else
{
i386_frameless_adjust_cache_hack (cache, frame_pc_unwind (next_frame));
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;
}
}
}
And the two helper functions are defined as:
/* 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] == '.');
}
--
Joel