From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21585 invoked by alias); 2 Apr 2005 14:26:57 -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 21396 invoked from network); 2 Apr 2005 14:26:41 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 2 Apr 2005 14:26:41 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DHjaC-0007Cm-BV; Sat, 02 Apr 2005 09:26:40 -0500 Date: Sat, 02 Apr 2005 14:26: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: <20050402142639.GA27550@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> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c53768$Blat.v2.4$d52008a0@zahav.net.il> User-Agent: Mutt/1.5.6+20040907i X-SW-Source: 2005-04/txt/msg00011.txt.bz2 On Sat, Apr 02, 2005 at 12:45:21PM +0300, Eli Zaretskii wrote: > > Date: Fri, 1 Apr 2005 12:19:47 -0500 > > From: Daniel Jacobowitz > > > > It means, literally, that the value is not available. The compiler has > > not saved it in somewhere that is still accessible, or has not told GDB > > properly where it was saved. > > 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. > > There's always a chance that it's a GDB bug, of course. > > Can you suggest a way for Rainer to see if this a GDB bug? For > example, could he somehow use readelf or similar tools to give some > information that would help us determine whether this is a GDB bug? You can use readelf to work it out. However, it requires passing familiarity with the DWARF specification. The GDB code for handling location lists is really not especially complicated; I don't expect problems in it. > 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. > I also find the string we print in this case too long. (You say that > in current CVS the output is a little nicer, but I don't see any > changes in CVS's dwarf2loc.c, which prints this, compared with GDB > 6.1; could you state in more detail which change you had in mind?) Only loclist_tracepoint_var_ref prints this message any more, assuming you are looking at a current version of the file. 2005-02-28 Daniel Jacobowitz * dwarf2loc.c (loclist_read_variable): Set optimized_out instead of reporting an error. * valprint.c (value_check_printable): New function. (common_val_print): New function. Use value_check_printable. (value_print): Use value_check_printable. * value.h (common_val_print): Add prototype. ... -- Daniel Jacobowitz CodeSourcery, LLC