This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [6.2] PROBLEMS file
- From: Joel Brobecker <brobecker at gnat dot com>
- To: Michael Elizabeth Chastain <mec dot gnu at mindspring dot com>
- Cc: eliz at gnu dot org, kettenis at chello dot nl, cagney at gnu dot org,gdb at sources dot redhat dot com
- Date: Thu, 22 Jul 2004 08:17:01 -0700
- Subject: Re: [6.2] PROBLEMS file
- References: <20040722093553.624FF4B104@berman.michael-chastain.com>
> Mark Kettenis writes:
> > There will always be cases where GDB will get confused and lose track.
> > In that case it will possibly provide an endless or very long backtrace
> > containing garbage.
>
> I'm okay with this part, as long as the user can easily get it
> out of it at the "press space to continue" prompt.
We saw the same sort of issues on Windows as well, trying to unwind
from functions in the ntdll DLL. Unfortunately in that case, we don't
get an infinite backtrace, we get a backtrace that doesn't provide
the part that the user is probably looking for (the part refering to
his code, before the call to the ntdll services). Something like this:
#0 0x7ffe0304 in ?? ()
#1 0x77f7f4af in ntdll!ZwWaitForSingleObject () from ntdll.dll
#2 0x77e7788b in WaitForSingleObjectEx () from /WINDOWS/system32/KERNEL32.DLL
#3 0x00000778 in ?? ()
#4 0x00000000 in ?? () from
#5 0x010df2c8 in ?? ()
#6 0x000003e8 in ?? ()
[snip]
#27 0x77e79d6a in WaitForSingleObject () from /WINDOWS/system32/KERNEL32.DLL
#28 0x00000778 in ?? ()
#29 0x000003e8 in ?? ()
#30 0x00000000 in ?? () from
#31 0x61074971 in siginterrupt () from /bin/cygwin1.dll
Previous frame inner to this frame (corrupt stack?)
In the backtrace above, only frame 0 to 2 are correct. After that,
GDB goes in limbo until it finally finds out that something is wrong.
The backtrace doesn't show how you got there, and I can imagine that
it could be fustrating for a user.
I have been working on and off on a small patch that would allow the
user to tell GDB to trust %ebp instead of trying to read the prologue
and guess the location of the return address for frameless functions.
The idea would be to offer this alternative when the current unwinder
fails.
I have a pretty simple minded patch that seems to be more or less
working, but I still have ~200 regressions compared to the current
unwinder. I would like to have a look at them, and if possible fix
them, before I submit what I have for review.
--
Joel