From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27034 invoked by alias); 18 May 2006 20:04:18 -0000 Received: (qmail 27000 invoked by uid 22791); 18 May 2006 20:04:17 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 18 May 2006 20:04:15 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.4/8.13.4) with ESMTP id k4IK4Bju016631; Thu, 18 May 2006 22:04:11 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.6/8.13.6) with ESMTP id k4IK4BMJ018782; Thu, 18 May 2006 22:04:11 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.6/8.13.6/Submit) id k4IK49Eh003764; Thu, 18 May 2006 22:04:09 +0200 (CEST) Date: Thu, 18 May 2006 20:43:00 -0000 Message-Id: <200605182004.k4IK49Eh003764@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: jimb@codesourcery.com CC: pgilliam@us.ibm.com, andrew.stubbs@st.com, brobecker@adacore.com, drow@false.org, mark.kettenis@xs4all.nl, gdb-patches@sourceware.org In-reply-to: (message from Jim Blandy on Thu, 18 May 2006 11:09:33 -0700) Subject: Re: [RFC] Move the frame zero PC check earlier 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> <20060516221837.GA15617@nevyn.them.org> <1147815745.3672.163.camel@dufur.beaverton.ibm.com> <20060517155729.GF27234@adacore.com> <446C3EB3.1040606@st.com> <1147969938.3672.168.camel@dufur.beaverton.ibm.com> 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/msg00403.txt.bz2 > From: Jim Blandy > Date: Thu, 18 May 2006 11:09:33 -0700 > > Okay --- I should be less equivocal. It is a bad idea to add this > command, obscure or otherwise. Engineers do this all the time when > they're having difficulty settling on a solution: they figure, hey, > let's let the users decide! It's presented as "giving the users more > control". Nobody wants to argue with that: every day we run into > something we wish we could tweak. Today I wished I could control the > 'From' address vixie cron uses in its mail messages. But it's a > mistake to treat this as an indication of the general desireability of > more switches and knobs. And half the time the knobs are just > workarounds for some other problem --- for example, I think the real > problem with my cron is that outgoing mail on my machine is > misconfigured. I 100% agree. Knobs are bad. Besides we'd be quibbling about the default setting for that knob ;-). > Nobody has written us saying they want to choose whether GDB treats a > zero return address as indicating the end of the stack. Rather, many > users have written us complaining that GDB displays extra frames at > the end of well-formed, non-corrupt stacks. And over the course of > the what seems like dozens of embedded GDB ports I've debugged since > 1997, I've come across the same behavior many times myself. If we're sure that zero return address actually signals the end of the stack, then indeed we should not print the extra frame. I'm not arguing with that. But that's defenitely > The only reason presented in this thread for displaying those frames > at all is that it can be an indication of a bug in GDB. No. There are two reasons why we should print those frames, and I consider both of them not to be an indication of a bug in GDB. 1. Because of a bug in the program you're debugging, it has overwritten the return address on the stack. Currently this causes the extra frame to be printed signalling the user that something is wrong. Daniel's patch changes this, but only if the return address is overwritten with zero. 2. It may be fundamentally impossible to unwind code produced by an optimizing compiler without additional debug info. We can't consider the fact that GDB gets the return address wrong if the debug info is missing a bug in GDB. Again the extra frame signals the user that something is wrong. Reason #2 is exactly the example Daniel gave in the message that started this thread. He noticed that something was wrong and fixed the problem by provide the necessary debug info. Now Daniel would probably have noticed the problem even if the extra frame had not been there. But it almost certainly would have taken him a bit more time, and a less experienced user might not have noticed it. > This is based on the (sound) general argument that GDB should be > picky about the state it examines, and report anomalies. But that > heuristic just doesn't make sense when the particular "anomaly" at > hand is, in fact, a valid and deliberate end-of-stack indicator on > many systems. Many systems, but certainly not all systems. At least i386, amd64, sparc and sparc64 don't use this convention. I'm sure there are others. From the traffic on the lists it sure seems as if 90% of the people are using gdb to remotely debug an ARM target from a Windows system, but there must be some sort of selection effect going on here, since more than 10% of our users must be using GDB on i386/amd64 GNU/Linux systems. Mark