Re: gdb stack trace problems (Addendum)

[Mark Kettenis <mark.kettenis@xs4all.nl>]

   Date: Fri, 22 Apr 2005 10:43:46 +0200
   From: Roland Schwingel <roland.schwingel@onevision.de>

   Hi Mark...

   Have you already had some time to look into it?

I did, but I didn't have find the time to reply yet ;-).

Anyway, there is a serious problem here.  The code you show is
basically undebuggable.  SleepEx is basically what we call a frameless
function; it doesn't set up its own stack frame.  This means the
debugger has to track all changes of the stack frame in this function
in order to be able to unwind the stack and provide a useful
backtrace.  However, since this Windows uses the convention that the
caller pushes function arguments on the stack, and the callee is
repsonsible for restoring the stack. this gets basically impossible.
I'm wondering whether Microsoft provides debug versions of its DLLs
that don't have this problem.

The only thing we can do here is trust the frame pointer, like we used
to do in the old days.  The problem with that is that it's very likely
to (silently) skip some function calls.  In your particular example it
probably would appear as if your code called SleepEx directly and
there would be no trace of Sleep at all.  That can be quite puzzling.

I'm thinking about adding an option to instruct gdb to "trust" the
frame pointer.  I'm not going to make it the default though.  I really
prefer seeing an abviously wrong backtrace over gdb silently skipping
function calls in its backtraces.

Mark