From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25754 invoked by alias); 2 Apr 2005 18:17:44 -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 25741 invoked from network); 2 Apr 2005 18:17:38 -0000 Received: from unknown (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org with SMTP; 2 Apr 2005 18:17:38 -0000 Received: from zaretski (IGLD-80-230-67-97.inter.net.il [80.230.67.97]) by romy.inter.net.il (MOS 3.5.6-GR) with ESMTP id AWV22454 (AUTH halo1); Sat, 2 Apr 2005 21:16:55 +0300 (IDT) Date: Sat, 02 Apr 2005 18:17:00 -0000 From: "Eli Zaretskii" To: Daniel Jacobowitz Message-ID: <01c537af$Blat.v2.4$c36667c0@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: gdb@sources.redhat.com, Reiner.Steib@gmx.de In-reply-to: <20050402142639.GA27550@nevyn.them.org> (message from Daniel Jacobowitz on Sat, 2 Apr 2005 09:26:40 -0500) Subject: Re: Variable "foo" is not available Reply-to: Eli Zaretskii References: <20050401171947.GA19058@nevyn.them.org> <01c53768$Blat.v2.4$d52008a0@zahav.net.il> <20050402142639.GA27550@nevyn.them.org> X-SW-Source: 2005-04/txt/msg00015.txt.bz2 > Date: Sat, 2 Apr 2005 09:26:40 -0500 > From: Daniel Jacobowitz > Cc: gdb@sources.redhat.com, Reiner.Steib@gmx.de > > > The compiler was GCC in this case. Is this a GCC bug? I cannot > > imagine how we would be able to explain the fact that _every_ frame in > > the backtrace has this message about some of the function parameters, > > other than by either a GCC bug or a GDB bug. > > Not every frame did. Most of the frames did, but they only represent a > tiny handful of different functions. 9 different functions were reported with such arguments. IMHO, that's too many for a rare situation. Moreover, Rainer says that he never saw such messages before in debugging Emacs, even though a typical Emacs backtrace always shows many invocations of these very functions (they are basic primitives of the Lisp interpreter, and Emacs runs Lisp code most of the time). > > In any case, it is rather unhelpful for the compiler to behave that > > way, since it means debugging optimized programs, once a flagship of > > GCC features wrt other compilers, is now very hard or even > > impractical. If this is intended behavior, I'd say it's a bad > > misfeature. > > This is not a change in compiler behavior, in any way. These are the > cases which would have printed garbage using any previous GCC release. > Backtraces for optimized code have always been unreliable. > > GCC does not take debugability into account at -O2 where it would > compromise any performance optimization; that's what -O2 asked for. It sounds like we were using 2 different compilers. My experience with GCC, based on many years, is that -O2 optimized code can be debugged quite well, as soon as you get accustomed to the execution thread jumping back and forth due to code rearrangements. In any real-life program with good code quality, the fraction of cases where a variable gets optimized away is very small. > Only loclist_tracepoint_var_ref prints this message any more, assuming > you are looking at a current version of the file. Ah, okay. I looked at the remaining string and assumed that this is what Rainer sees. Sorry.