From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gdb-return-32966-listarch-gdb=sources.redhat.com@sourceware.org>
Received: (qmail 11028 invoked by alias); 3 Sep 2008 04:37:10 -0000
Received: (qmail 11018 invoked by uid 22791); 3 Sep 2008 04:37:09 -0000
X-Spam-Check-By: sourceware.org
Received: from bluesmobile.specifix.com (HELO bluesmobile.specifix.com) (216.129.118.140)     by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 03 Sep 2008 04:36:34 +0000
Received: from [127.0.0.1] (bluesmobile.specifix.com [216.129.118.140]) 	by bluesmobile.specifix.com (Postfix) with ESMTP id 2DCA63BCE2; 	Tue,  2 Sep 2008 21:36:33 -0700 (PDT)
Subject: Re: how to examine data with compiler optimization option set?
From: Michael Snyder <msnyder@specifix.com>
To: "Frank Ch. Eigler" <fche@redhat.com>
Cc: Michael Snyder <msnyder@vmware.com>, Joel Brobecker <brobecker@adacore.com>,  Robert Dewar <dewar@adacore.com>, "jreiver@free.fr" <jreiver@free.fr>, "gdb@sourceware.org" <gdb@sourceware.org>
In-Reply-To: <y0mljyaudzb.fsf@ton.toronto.redhat.com>
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>  <y0mljyaudzb.fsf@ton.toronto.redhat.com>
Content-Type: text/plain
Date: Wed, 03 Sep 2008 04:37:00 -0000
Message-Id: <1220416592.3389.4.camel@localhost.localdomain>
Mime-Version: 1.0
X-Mailer: Evolution 2.10.3 (2.10.3-7.fc7)
Content-Transfer-Encoding: 7bit
X-IsSubscribed: yes
Mailing-List: contact gdb-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <gdb.sourceware.org>
List-Subscribe: <mailto:gdb-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/gdb/>
List-Post: <mailto:gdb@sourceware.org>
List-Help: <mailto:gdb-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: gdb-owner@sourceware.org
X-SW-Source: 2008-09/txt/msg00018.txt.bz2

On Tue, 2008-09-02 at 23:04 -0400, Frank Ch. Eigler wrote:
> Michael Snyder <msnyder@vmware.com> writes:
> 
> > [...]
> > I don't think there is any possibility whatsoever of
> > somehow generating location codes for the variables in
> > the example.
> >
> > Those values are simply not kept anywhere.  GCC will replace
> > them all with the constant, "3".
> 
> You might be surprised.  Some RH engineers are working along these
> lines.  Being able to debug (<=> probe/trace) optimized code is
> becoming more and more important, and gcc is slowly getting into the
> mood to help.

I'm more than willing to be surprised...
it will be a pleasant one.  ;-)