From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30905 invoked by alias); 2 Sep 2008 21:45:50 -0000 Received: (qmail 30894 invoked by uid 22791); 2 Sep 2008 21:45:50 -0000 X-Spam-Check-By: sourceware.org Received: from wmproxy1-g27.free.fr (HELO wmproxy1-g27.free.fr) (212.27.42.91) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 02 Sep 2008 21:45:11 +0000 Received: from imp8-g19.priv.proxad.net (imp8-g19.priv.proxad.net [172.20.243.50]) by wmproxy1-g27.free.fr (Postfix) with ESMTP id D382E2B082; Wed, 3 Sep 2008 00:09:09 +0200 (CEST) Received: by imp8-g19.priv.proxad.net (Postfix, from userid 33) id 7C81111AE8; Tue, 2 Sep 2008 23:40:32 +0200 (CEST) Received: from ([82.227.65.140]) by imp.free.fr (IMP) with HTTP for ; Tue, 02 Sep 2008 23:40:32 +0200 Message-ID: <1220391632.48bdb2d04bfd7@imp.free.fr> Date: Tue, 02 Sep 2008 21:45:00 -0000 From: jreiver@free.fr To: Robert Dewar Cc: gdb@sourceware.org Subject: Re: how to examine data with compiler optimization option set? References: <1220390777.48bdaf79617dd@imp.free.fr> <48BDB1B0.4040703@adacore.com> In-Reply-To: <48BDB1B0.4040703@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit User-Agent: Internet Messaging Program (IMP) 3.2.8 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/msg00010.txt.bz2 Yes, I knew that the optimization option removes the visibility for a, b and c. But GDB user manual seemed to say that you can still view them with providing -gstabs or -gdwarf2 option, in addition to the -O[1|2|3] option you might want to keep. Isn't that possible at all? (I am currently evaluating the debugging facilities of gdb) Regards, J R Quoting Robert Dewar : > J R wrote: > > Extract of GDB user manual: > > > > "Another possible effect of compiler optimizations is to optimize unused > > variables out of existence, or assign variables to registers (as opposed to > > memory addresses). Depending on the support for such cases offered by the > debug > > info format used by the compiler, GDB might not be able to display values > for > > such local variables. > > > > To solve such problems, either recompile without optimizations, or use a > > different debug info format, if the compiler supports several such formats. > For > > example, GCC, the GNU C/C++ compiler usually supports the `-gstabs' option. > > `-gstabs' produces debug info in a format that is superior to formats such > as > > COFF. You may be able to use DWARF2 (`-gdwarf-2'), which is also an > effective > > form for debug info. See section `Options for Debugging Your Program or GNU > CC' > > in Using GNU CC, for more information." > > > > I wanted to keep the optimization option, so I tried to recompile with GCC, > > using the -gstabs and -gdwarf-2 options, and even -g3, with this very > simple > > program: > > int main(void){ > > int a = 1; > > int b = 2; > > int c = a+b; > > > > printf("Value c = %d \n", c); > > } > > > > But still couldn't display the variables a, b and c! > > That's because if you ask for the compiler to optimize, it > will change this program to > > int main(void){ > printf ("Value c = %d \n", 3"); > } > > if it was a bit cleverer, it might even change it to > > int main(void){ > printf ("Value c = 3 \n"); > } > > but in either case a,b, and c are gone! > > It might be theoretically possible to retain the values of > a,b,c in the debugging information, but this is a huge amount > of work, and not something likely to be done in the near future. > > > Is there a particular compiling option configuration to set? > > Yes, -O0, if you want junk code kept around for debugging > purposes, you have to ask for it! > > > > Is there a particular compiling option configuration to set? > > > > Many thanks in advance. > > > > Regards. > >