Re: Strange stack trace on Windows

[Roland Schwingel <roland at schwingel dot com>]

Hi Joel...

Thanks for your reply....
gdb-owner@sourceware.org wrote on 17.03.2009 14:19:49:
> > 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 :)
It is of very good use. If I only could get the stepping now right... ;-)

> > 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.
Yes... :-) This is true... I already observed this... It has disappeared.

> 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.
This list could get quite very long. I already considered to do something
like that, but just as some kind of last resort as the list could get 
quite very
long. It must contain quite every windows function. Or completely
match dll names like msvcrt.dll

Wouldn't it be possible to also adjust gdb's stepping code to work with
your patch? Or (also not really nice, but maybe cleaner) to
only use your patch for stack dumping. For stepping rely on the
"other" (means current) frame code.

It is quite painful to use gdb on windows for quite a while now.
Windows, whether one may like it or not, is a major platform
and gdb should also operate well here. I am fighting for a long time
with these problems now. Isn't there a general solution thinkable?
GDB is cool piece of software. For me it is "THE" debugger but
this problem transforms more and more into killer problem here.

> PS: It looks like I'll have to implement the same type of patch for
>     x86_64-windows.
Might be useful, too... At least for me.... ;-)

Roland