From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9824 invoked by alias); 3 Sep 2008 00:05:50 -0000 Received: (qmail 9815 invoked by uid 22791); 3 Sep 2008 00:05:49 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 03 Sep 2008 00:05:15 +0000 Received: from mailhost5.vmware.com (mailhost5.vmware.com [10.16.68.131]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 4E7E234017; Tue, 2 Sep 2008 17:05:13 -0700 (PDT) Received: from [10.20.92.218] (promb-2s-dhcp218.eng.vmware.com [10.20.92.218]) by mailhost5.vmware.com (Postfix) with ESMTP id 43767DC05D; Tue, 2 Sep 2008 17:05:13 -0700 (PDT) Message-ID: <48BDD4B7.5060503@vmware.com> Date: Wed, 03 Sep 2008 00:05:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Joel Brobecker CC: Robert Dewar , "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> In-Reply-To: <20080902215623.GA3779@adacore.com> 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/msg00014.txt.bz2 Joel Brobecker wrote: > The documentation is slightly outdated, as stabs has hardly any support > for debugging optimized code. Better stick with DWARF2/3. > >>> Isn't that possible at all? (I am currently evaluating the debugging >>> facilities >>> of gdb) >> No it is not possible. > > Note that the debugger behavior is usually expected considering > the debugging information generated by the compiler. I heard there > is some effort to improve the debugging information, but generally > speaking, debugging optimized code right now can be tricky. 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".