From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16204 invoked by alias); 2 Apr 2005 21:05:51 -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 16142 invoked from network); 2 Apr 2005 21:05:43 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 2 Apr 2005 21:05:43 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50 #1 (Debian)) id 1DHpoM-0004Ni-6o; Sat, 02 Apr 2005 16:05:42 -0500 Date: Sat, 02 Apr 2005 21:05: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: <20050402210541.GA16758@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> <20050402184023.GA20247@nevyn.them.org> <01c537c6$Blat.v2.4$427763a0@zahav.net.il> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <01c537c6$Blat.v2.4$427763a0@zahav.net.il> User-Agent: Mutt/1.5.8i X-SW-Source: 2005-04/txt/msg00018.txt.bz2 On Sat, Apr 02, 2005 at 11:54:08PM +0300, Eli Zaretskii wrote: > > 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? What are you suggesting we do about it? There are only two options: make the argument remain available, which carries a performance penalty, or politely inform the user that it is unavailable. The user asked for no performance penalties. I'm not trying to dismiss your experience; but I've worked on this code in the compiler, and it's just not designed to do what you're expecting. > > 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? Very easily. Suppose you have two incoming arguments in registers; GCC will do this automatically for static functions even on i386, which normally uses a stack convention. The first is used after a function call, so it is preserved by saving it to the stack. The second is not used after the function call, so the compiler has no reason to allocate a save slot for it, and no reason to store it to memory before the function call. With stack-based argument passing, GCC may be claiming an argument is unavailable when the function's local copy is dead, when a copy still exists on the stack somewhere. I don't know if it will do that or not. GDB can not assume that the argument is available in the incoming stack slot, since it could be reused for other data. -- Daniel Jacobowitz CodeSourcery, LLC