From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28427 invoked by alias); 23 Jul 2004 09:24:06 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 28420 invoked from network); 23 Jul 2004 09:24:04 -0000 Received: from unknown (HELO walton.kettenis.dyndns.org) (213.93.77.109) by sourceware.org with SMTP; 23 Jul 2004 09:24:04 -0000 Received: from elgar.kettenis.dyndns.org (elgar.kettenis.dyndns.org [192.168.0.2]) by walton.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i6N9NYPL001941; Fri, 23 Jul 2004 11:23:34 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: from elgar.kettenis.dyndns.org (localhost [127.0.0.1]) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6) with ESMTP id i6N9NYAA005362; Fri, 23 Jul 2004 11:23:34 +0200 (CEST) (envelope-from kettenis@elgar.kettenis.dyndns.org) Received: (from kettenis@localhost) by elgar.kettenis.dyndns.org (8.12.6p3/8.12.6/Submit) id i6N9NWOt005359; Fri, 23 Jul 2004 11:23:32 +0200 (CEST) Date: Fri, 23 Jul 2004 11:22:00 -0000 Message-Id: <200407230923.i6N9NWOt005359@elgar.kettenis.dyndns.org> From: Mark Kettenis To: eliz@gnu.org CC: brobecker@gnat.com, mec.gnu@mindspring.com, cagney@gnu.org, gdb@sources.redhat.com In-reply-to: <6654-Fri23Jul2004110924+0300-eliz@gnu.org> Subject: Re: [6.2] PROBLEMS file References: <20040722093553.624FF4B104@berman.michael-chastain.com> <20040722151701.GA20596@gnat.com> <2914-Thu22Jul2004221106+0300-eliz@gnu.org> <200407221926.i6MJQIbG001753@elgar.kettenis.dyndns.org> <6654-Fri23Jul2004110924+0300-eliz@gnu.org> X-SW-Source: 2004-07/txt/msg00294.txt.bz2 Date: Fri, 23 Jul 2004 11:09:25 +0200 From: "Eli Zaretskii" 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