This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]