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: Roland Schwingel <roland dot schwingel at onevision dot de>
- Cc: gdb <gdb at sourceware dot org>
- Date: Tue, 17 Mar 2009 09:19:49 -0400
- Subject: Re: Strange stack trace on Windows
- References: <49BF903D.6090900@onevision.de>
> With the patch from Joel I get really good strack traces back in this case.
Glad to hear that you were able to put the patch to good use :)
> But there is mabye a sideeffect of this patch when stepping thru an
> application.
[...]
> As soon as I type next on one of the setbuf() functions gdb steps
> directly to the assembly code of setbuf not over it as I would like to
> have it...
I suspect that this is because we fail to detect that the caller of
setbuf if "function", most likely because the setbuf function does
not setup a frame. You can confirm this by requesting a backtrace
after you landed inside "setbuf". If your "function" has disappeared
from the backtrace, you know.
As I explained back then, this patch is a compromise: You'll win some,
and lose some. But you can change a bit the compromise by deciding that
certain routines should be excluded from the heuristics. For instance,
you can expand i386_in_dll to not only check whether the PC is inside
a DLL, but also check the name of the function associated to that PC.
One possibility is to only match the name of the routines you know are
causing trouble. Another way it to exclude all frameless routines that
you know GDB can actually unwind from.
At AdaCore, we decided to stay away from that, because it's very hacky
and OS version dependent.
PS: It looks like I'll have to implement the same type of patch for
x86_64-windows.
--
Joel