This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: [6.2] PROBLEMS file
Date: Fri, 23 Jul 2004 11:09:25 +0200
From: "Eli Zaretskii" <eliz@gnu.org>
I did. It's possible that I misunderstand something, or even make
some stupid mistake, but there's no need to assume I didn't read the
message to which I responded.
Sorry Eli. I lost my temper a bit. The issue keeps coming up again
and again :-(.
> Frame #2 is executing Microsoft shit. I
> don't know what debugging format they use, and I don't think they ship
> their official releases with debugging info in it.
Sorry, I fail to see the relevance of this. No matter what debug info
is there, GDB should be able to track stack frames, shouldn't it? And
it actually does at least once: it succeeds in showing
WaitForSingleObjectEx as the caller of ntdll!ZwWaitForSingleObject.
Why can't it continue from there? Unless someone can prove to us (by
disassemblying at that spot) that the functions which give us trouble
are frameless, I'm not sure we should dismiss this case so easily.
Joel and I looked at the disassembled code, it's a complicated
function that defenitely doesn't set up a proper frame.
> The code looks like hand-optimized assembler.
Btw, Joel, could you please see if GDB 5.x did succeed to show a good
backtrace in this very case?
It (silently) skipped a few frames.
Anyway, the real reason I said what I did was that I see something
very similar in a DJGPP-compiled Emacs; see below. Now this is pure
GCC code and DJGPP runtime, no Microsoft shit anywhere in sight, and I
can tell you with 100% certainty that no hand-optimized assembly is
used anywhere in the frames that are misbehaving in GDB. It's all
part of Emacs sources written in C, you can actually look up the
sources in the Emacs codebase. Doesn't it look similar to what Joel
posted?
In some ways, yes. GDB loses track after frame #21, but I doubt
whether recursive_edit_1 is a frameless function. Can you post a
dissassembly of that function?
Mark