From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24181 invoked by alias); 3 Sep 2008 21:43:13 -0000 Received: (qmail 24173 invoked by uid 22791); 3 Sep 2008 21:43:13 -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; Wed, 03 Sep 2008 21:42:34 +0000 Received: from localhost (localhost.localdomain [127.0.0.1]) by filtered-rock.gnat.com (Postfix) with ESMTP id 5F2E72A96D9; Wed, 3 Sep 2008 17:42:32 -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 h2nD-xAy8nQG; Wed, 3 Sep 2008 17:42:32 -0400 (EDT) Received: from [127.0.0.1] (nile.gnat.com [205.232.38.5]) by rock.gnat.com (Postfix) with ESMTP id 17B002A96CE; Wed, 3 Sep 2008 17:42:32 -0400 (EDT) Message-ID: <48BF04C6.8030108@adacore.com> Date: Wed, 03 Sep 2008 21:43:00 -0000 From: Robert Dewar User-Agent: Thunderbird 2.0.0.16 (Windows/20080708) MIME-Version: 1.0 To: Eli Zaretskii CC: "Frank Ch. Eigler" , 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> In-Reply-To: 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/msg00023.txt.bz2 Eli Zaretskii wrote: >> Cc: Joel Brobecker , Robert Dewar , "jreiver@free.fr" , "gdb@sourceware.org" >> From: fche@redhat.com (Frank Ch. Eigler) >> Date: Tue, 02 Sep 2008 23:04:24 -0400 >> >> 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'll applaud this mood. When I started using GCC (it was v1.x back > then), being able to efficiently debug optimized code was one of GCC's > most attractive features. When that feature was lost in GCC 3.x, I > was quite shocked. I'd love to have that back again. Well you always had local variables disappearing in earlier versions but enough worked so you could debug, in particular parameters were always available and reliable.