From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 9628 invoked by alias); 9 May 2005 16:39:50 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 9434 invoked from network); 9 May 2005 16:39:39 -0000 Received: from unknown (HELO nevyn.them.org) (66.93.172.17) by sourceware.org with SMTP; 9 May 2005 16:39:39 -0000 Received: from drow by nevyn.them.org with local (Exim 4.50) id 1DVBIA-0005sQ-SV; Mon, 09 May 2005 12:39:38 -0400 Date: Mon, 09 May 2005 16:39:00 -0000 From: Daniel Jacobowitz To: Tigran Aivazian Cc: gdb@sources.redhat.com Subject: Re: gdb problems with -O1 on x86_64 architecture. Message-ID: <20050509163938.GA22498@nevyn.them.org> Mail-Followup-To: Tigran Aivazian , gdb@sources.redhat.com References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.8i X-SW-Source: 2005-05/txt/msg00113.txt.bz2 On Mon, May 09, 2005 at 05:11:27PM +0100, Tigran Aivazian wrote: > Hello, > > I enclosed a small program which shows a bug in gdb --- it coredumps if > you try to look at the backtrace. Here is how to reproduce it: > > 1. Compile with -O1 optimization option: > > $ gcc -g -Wall -O1 uvar.c -o uvar-O1 It is unlikely that anyone else can reproduce this, because it depends on what your compiler is generating. What version is it? What patches are applied? You may have better luck if you attach a built binary. > Also, with application compiled with -O0 everything works perfectly. But > with -O2 I get most of the function arguments marked as "optimized away". > Well, surely they are NOT optimized away, but the debug info is stored in > such a way (presumably difficult to decode according to DWARF2 rules) that > makes gdb's life very hard to decode them, right? Is there any way to get > gdb to see function arguments for the case of -O2 optimization? No, more likely they are optimized away - not saved because they are no longer available. There's no way to be sure without a binary. In your test case, they probably _are_ gone. They are never referenced after the function calls, so there's no benefit in saving them to the stack and restoring them later. -- Daniel Jacobowitz CodeSourcery, LLC