From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23127 invoked by alias); 4 Sep 2008 14:09:01 -0000 Received: (qmail 23043 invoked by uid 22791); 4 Sep 2008 14:08:59 -0000 X-Spam-Check-By: sourceware.org Received: from rock.gnat.com (HELO rock.gnat.com) (205.232.38.15) by sourceware.org (qpsmtpd/0.31) with ESMTP; Thu, 04 Sep 2008 14:08:20 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id C4D342A95D6; Thu, 4 Sep 2008 10:08:18 -0400 (EDT) Received: from rock.gnat.com ([127.0.0.1]) by localhost (rock.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id bxIzkad-xfUf; Thu, 4 Sep 2008 10:08:18 -0400 (EDT) Received: from [127.0.0.1] (nile.gnat.com [205.232.38.5]) by rock.gnat.com (Postfix) with ESMTP id 8DAFE2A9744; Thu, 4 Sep 2008 10:08:16 -0400 (EDT) Message-ID: <48BFEBCE.8080102@adacore.com> Date: Thu, 04 Sep 2008 14:09:00 -0000 From: Robert Dewar User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Paul Koning CC: schwab@suse.de, eliz@gnu.org, fche@redhat.com, msnyder@vmware.com, brobecker@adacore.com, jreiver@free.fr, gdb@sourceware.org Subject: Re: how to examine data with compiler optimization option set? References: <1220390777.48bdaf79617dd@imp.free.fr> <48BDB1B0.4040703@adacore.com> <1220391632.48bdb2d04bfd7@imp.free.fr> <48BDB4E2.9010301@adacore.com> <20080902215623.GA3779@adacore.com> <48BDD4B7.5060503@vmware.com> <48BF04C6.8030108@adacore.com> <48BFBE10.30902@adacore.com> <18623.60121.742830.903401@gargle.gargle.HOWL> In-Reply-To: <18623.60121.742830.903401@gargle.gargle.HOWL> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-09/txt/msg00027.txt.bz2 Paul Koning wrote: > Is the problem inadequate debug information (i.e., the values are > there, but there isn't debug data that points to the correct registers > or stack slots) -- or is the problem that the values you want to see > are dead by the time you get to them and the registers holding them > have been reused by then? Or something in between, i.e., the values > are technically dead, but the registers have NOT yet been reused so > the debug information can (and should) still show where they are. Well on entry to a function, (if you breakpoint on entry), the parameters cannot have been overwritten yet I would think! > > paul