From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 10648 invoked by alias); 16 May 2007 14:43:03 -0000 Received: (qmail 10638 invoked by uid 22791); 16 May 2007 14:43:02 -0000 X-Spam-Check-By: sourceware.org Received: from return.false.org (HELO return.false.org) (66.207.162.98) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 16 May 2007 14:42:54 +0000 Received: from return.false.org (localhost [127.0.0.1]) by return.false.org (Postfix) with ESMTP id 30A304B267; Wed, 16 May 2007 09:42:51 -0500 (CDT) Received: from caradoc.them.org (dsl093-172-095.pit1.dsl.speakeasy.net [66.93.172.95]) by return.false.org (Postfix) with ESMTP id EBBEC4B262; Wed, 16 May 2007 09:42:50 -0500 (CDT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1HoKiI-0001IK-7N; Wed, 16 May 2007 10:42:50 -0400 Date: Wed, 16 May 2007 14:43:00 -0000 From: Daniel Jacobowitz To: Luis Machado Cc: gdb-patches@sources.redhat.com Subject: Re: [patch] Backtrace prints wrong argument value Message-ID: <20070516144250.GD24682@caradoc.them.org> Mail-Followup-To: Luis Machado , gdb-patches@sources.redhat.com References: <1177527233.12599.42.camel@localhost> <20070425191304.GA1283@caradoc.them.org> <1179293640.4323.16.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1179293640.4323.16.camel@localhost> User-Agent: Mutt/1.5.15 (2007-04-09) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2007-05/txt/msg00279.txt.bz2 On Wed, May 16, 2007 at 02:34:00AM -0300, Luis Machado wrote: > On Wed, 2007-04-25 at 15:13 -0400, Daniel Jacobowitz wrote: > > A valid location list for func1 could say that arg1 is valid > > in r20 during the call to abort; the -1 puts us on the call, instead > > of after it, in the unrelated func2. > > > > I believe this is considered a known weakness of the DWARF > > representation, which does not represent state before an instruction > > separately from state after it. The debug info does not tell us > > whether the location is valid in the middle of the call. > > Do you have anything in mind in order to better handle this situation > instead of showing wrong values in backtrace every now and then? > > >From your comment it wasn't clear if hiding possibly wrong values is > worse than showing them sometimes. There is simply not enough information in the debug info to handle this correctly. Let me give you another example: move var to r3 test something if true, branch to Lfoo call abort, which clobbers r3 Lfoo: do something with r3 At every instruction after the move, the debug info should say that var is in r3. Right? No matter which location we pick here, while backtracing from abort, we'll print the wrong value for var and there's no point where the debug info will say it is undefined. If you want us to get this right using DWARF info, I believe your only choice is to approach the DWARF working group about it. Now, in GDB we may have other options. We might be able to get the list of call clobbered registers based on the ABI. Compare with s390, which already does this (dwarf2_frame_set_init_reg). Does adding this to PowerPC help your example any? -- Daniel Jacobowitz CodeSourcery