From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28653 invoked by alias); 16 May 2006 22:19:29 -0000 Received: (qmail 28635 invoked by uid 22791); 16 May 2006 22:19:26 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Tue, 16 May 2006 22:18:39 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1Fg7sD-00048T-Gf; Tue, 16 May 2006 18:18:37 -0400 Date: Tue, 16 May 2006 22:46:00 -0000 From: Daniel Jacobowitz To: Mark Kettenis Cc: gdb-patches@sourceware.org Subject: Re: [RFC] Move the frame zero PC check earlier Message-ID: <20060516221837.GA15617@nevyn.them.org> Mail-Followup-To: Mark Kettenis , gdb-patches@sourceware.org References: <20060510180312.GA12606@nevyn.them.org> <200605130946.k4D9kZ2M001331@elgar.sibelius.xs4all.nl> <20060513151338.GB3721@nevyn.them.org> <200605131642.k4DGgiqa018273@elgar.sibelius.xs4all.nl> <20060516204503.GC13210@nevyn.them.org> <200605162137.k4GLbZiS014187@elgar.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200605162137.k4GLbZiS014187@elgar.sibelius.xs4all.nl> User-Agent: Mutt/1.5.11+cvs20060403 X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-05/txt/msg00368.txt.bz2 On Tue, May 16, 2006 at 11:37:35PM +0200, Mark Kettenis wrote: > So there are several conventions, and these make sense for a specific > ISA or perhaps even a specific OS. So... would you be happier if I set a gdbarch flag to control this? I still think this is the wrong choice, and I would prefer not to do it without opinions from a few of GDB's other maintainers, but a compromise is better than nothing at all. It's this statement in particular that I am disagreeing with: > But the zero PC is *not* universal. Therefore it should be treated > the same as the non-zero garbage PC. Not every system uses it, but no one overloads it to mean anything else during correct operation and it is unambiguous. I think that does make it universal. And you can not draw clear target lines on where it is and is not used; for instance, I think at least one Linux kernel debugging stub ends backtraces this way. That might not be current information; we made up a GDB convention for dwarf2 unwind terminators and I've been trying to persuade the kernel developers to use it. But even ignoring the issues of non-free operating systems (which I have a different opinion on supporting, as you know), I think that adapting existing runtimes to the debugger is putting the cart before the horse, and free operating systems can use this convention too, and there's a lot of them out there. By the way, if you go ahead and remove that %ebp check, you're going to introduce exactly this problem for current glibc on IA-32; suddenly you'll get a bogus frame below thread_start after clone in every thread. > And this is exactly the case where I think the jagged end of the > backtrace is important. It indicates that GDB lost track somewhere > and that the backtrace can't be trusted. I find that the backtrace stopping at a random function is clear enough, personally. > I cannot imagine that a single extra frame to be a serious annoyance. > I can see that the extra frame looses its signalling function on > systems where it's seen a lot in cases where the stack actually ends > that way. For you, or for me, it is not a serious annoyance. For users a lot further out from the system, on top of an IDE and a development environment, it is confusing. For the folks who have to document those IDEs and answer customer support questions about them when their customers get confused, it becomes a real problem. It's something ugly and incorrect on their backtrace window that needs an apologetic paragraph in the manual. That's my benchmark for cosmetic bugs that are worth fixing; if I was answering "why is it that way" and the best reason I could give would be an apology, then it needs to be fixed. That's where the lion's share of GDB use is coming to be - on top of GUIs like KDevelop and Eclipse and probably a dozen others, for users with less low-level experience. -- Daniel Jacobowitz CodeSourcery