From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11426 invoked by alias); 2 Apr 2005 20:58:39 -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 11357 invoked from network); 2 Apr 2005 20:58:33 -0000 Received: from unknown (HELO legolas.inter.net.il) (192.114.186.24) by sourceware.org with SMTP; 2 Apr 2005 20:58:33 -0000 Received: from zaretski (IGLD-80-230-67-97.inter.net.il [80.230.67.97]) by legolas.inter.net.il (MOS 3.5.6-GR) with ESMTP id EBI47114 (AUTH halo1); Sat, 2 Apr 2005 23:57:58 +0300 (IDT) Date: Sat, 02 Apr 2005 20:58:00 -0000 From: "Eli Zaretskii" To: Daniel Jacobowitz Message-ID: <01c537c6$Blat.v2.4$427763a0@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: <20050402184023.GA20247@nevyn.them.org> (message from Daniel Jacobowitz on Sat, 2 Apr 2005 13:40:23 -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> <01c537af$Blat.v2.4$c36667c0@zahav.net.il> <20050402184023.GA20247@nevyn.them.org> X-SW-Source: 2005-04/txt/msg00017.txt.bz2 > Date: Sat, 2 Apr 2005 13:40:23 -0500 > From: Daniel Jacobowitz > Cc: gdb@sources.redhat.com, Reiner.Steib@gmx.de > > > 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. If it isn't rare, we should do something about it, I think. > It's easy to not notice the problem with earlier versions of GCC. I'm using GCC 3.x since the year 2001, and the DWARF 2 debug info as the default since more than a year ago. I think this is long enough not to dismiss my experience. Anyway, I don't really understand what is your intent. Are you saying that this is what we should expect from optimized code in GDB, and that nothing should or could be done about it? > On non-DWARF targets or old versions, the variables will appear to > be available - even if their correct values no longer exist in > memory. We are talking about function call arguments here, not just about any local variables. Can you tell what compiler optimizations could cause what Reiner reported: that the first argument is available to GDB, but the second is not?