Re: gdb stack trace problems (Addendum)

[Roland Schwingel <roland dot schwingel at onevision dot de>]

Hi...

gdb-owner@sources.redhat.com wrote on 09.05.2005 01:19:53:
> On Sun, May 08, 2005 at 03:30:20PM +0200, Mark Kettenis wrote:
> >   Date: Mon, 02 May 2005 09:03:08 +0200
> >   From: Roland Schwingel <roland.schwingel@onevision.de>
> >
> >   Hi Mark...
> >
> >   Have you already had some time to look into my results with your 
patch to
> >   the i386 stack unwinder? At basically it could work but obviously it
> >   is not advancing to the next stack frame... Attached you will 
find my
> >   results
> >
> >This isn't very encouraging.  My approach obviously isn't working very
> >well.  My suggestion is to go for a Windows-specific solution, where
> >one would use a special unwinder for the sort of undebuggable code
> >that's found in the Windows system DLLs.  But I'm afraid I can't
> >really do much since I don't have a Windows system.  Chris, is there
> >any change you can hack something like this into i386-cygwin-tdep.c?
>
> What kind of windows-specific solution do you have in mind?  How would
> you know what to unwind?  You could potentially figure out that you're
> stuck in a system function but that doesn't mean that you know the
> state of the stack.
>
> If a function doesn't set up a frame pointer and there is no debugging
> information available, how would one derive a stack frame?  I could
> imagine a really complicated "search the stack" technique but I can't
> see how it would ever be foolproof.
Well... GDB 5.3 was able to dump a correct stack in this case... So it was
possible to do in the past. Marks patch for gdb 6.x was not really 
really bad.
It dumped the first stack frame now "somewhat" correctly, but failed to 
advance
to the next stack frame.

Maybe we could implement something similar to the gdb 5.3 code but with all
the benefits from the 6.x changes?

Roland