From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18302 invoked by alias); 2 Apr 2005 09:49:53 -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 18188 invoked from network); 2 Apr 2005 09:49:45 -0000 Received: from unknown (HELO romy.inter.net.il) (192.114.186.66) by sourceware.org with SMTP; 2 Apr 2005 09:49:45 -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 AWU27462 (AUTH halo1); Sat, 2 Apr 2005 12:49:09 +0300 (IDT) Date: Sat, 02 Apr 2005 09:49:00 -0000 From: "Eli Zaretskii" To: Daniel Jacobowitz Message-ID: <01c53768$Blat.v2.4$d52008a0@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: <20050401171947.GA19058@nevyn.them.org> (message from Daniel Jacobowitz on Fri, 1 Apr 2005 12:19:47 -0500) Subject: Re: Variable "foo" is not available Reply-to: Eli Zaretskii References: <20050401171947.GA19058@nevyn.them.org> X-SW-Source: 2005-04/txt/msg00008.txt.bz2 > 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. > 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? Rainer, could you please use the GDB "up" command a few times, and after each time type "info args" and see whether that does give you the arguments of the function call in that frame? > What this normally means is that you are using optimization, and the value > of tag is not referenced after the function call, so the compiler did > not save it anywhere. If this happens frequently with GCC, we should document it in the manual. Rainer, could you please tell exactly which compiler switches were used to build that version of Emacs? 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. 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?) Something like > #61 0x000000000054c960 in internal_catch (tag=) would be much better, IMHO. > and following function arguments won't be chopped off. That would be certainly better, but again, I don't see that change in the current CVS. In any case, if Rainer could build the latest snapshot of GDB and see if the values of the rest of the function call arguments are printed (as opposed to all of them generating the "not available" message), it would perhaps tell us something about the underlying problem.