From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15070 invoked by alias); 2 Apr 2005 18:40:32 -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 14974 invoked from network); 2 Apr 2005 18:40:25 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 2 Apr 2005 18:40:25 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DHnXk-0005Qt-12; Sat, 02 Apr 2005 13:40:24 -0500 Date: Sat, 02 Apr 2005 18:40:00 -0000 From: Daniel Jacobowitz To: Eli Zaretskii Cc: gdb@sources.redhat.com, Reiner.Steib@gmx.de Subject: Re: Variable "foo" is not available Message-ID: <20050402184023.GA20247@nevyn.them.org> Mail-Followup-To: Eli Zaretskii , gdb@sources.redhat.com, Reiner.Steib@gmx.de References: <20050401171947.GA19058@nevyn.them.org> <01c53768$Blat.v2.4$d52008a0@zahav.net.il> <20050402142639.GA27550@nevyn.them.org> <01c537af$Blat.v2.4$c36667c0@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c537af$Blat.v2.4$c36667c0@zahav.net.il> User-Agent: Mutt/1.5.6+20040907i X-SW-Source: 2005-04/txt/msg00016.txt.bz2 On Sat, Apr 02, 2005 at 09:13:06PM +0300, Eli Zaretskii wrote: > > 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. I didn't say it was 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). I would assume he's using a newer compiler than he used to. > > > 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. This definitely has not been my experience since the beginning of the 3.x series; it was more true in the 2.x series, when GCC's optimizers were much weaker. As I said, it is a design goal for GCC to optimize efficiently regardless of debugability when you ask for optimization. It's gotten better at that over the years. Dwarf supports various sophisticated mechanisms for debugging optimized code; GDB supports almost none of them. It's easy to not notice the problem with earlier versions of GCC. On non-DWARF targets or old versions, the variables will appear to be available - even if their correct values no longer exist in memory. -- Daniel Jacobowitz CodeSourcery, LLC