From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11611 invoked by alias); 16 May 2007 05:34:17 -0000 Received: (qmail 11599 invoked by uid 22791); 16 May 2007 05:34:16 -0000 X-Spam-Check-By: sourceware.org Received: from igw2.br.ibm.com (HELO igw2.br.ibm.com) (32.104.18.25) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 16 May 2007 05:34:09 +0000 Received: from mailhub3.br.ibm.com (mailhub3 [9.18.232.110]) by igw2.br.ibm.com (Postfix) with ESMTP id F38C55BD7E for ; Wed, 16 May 2007 02:26:16 -0300 (BRT) Received: from d24av01.br.ibm.com (d24av01.br.ibm.com [9.18.232.46]) by mailhub3.br.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l4G5Y4L01724450 for ; Wed, 16 May 2007 02:34:05 -0300 Received: from d24av01.br.ibm.com (loopback [127.0.0.1]) by d24av01.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l4G5W2Tq008339 for ; Wed, 16 May 2007 02:32:02 -0300 Received: from [9.18.196.166] ([9.18.196.166]) by d24av01.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l4G5W06g008332; Wed, 16 May 2007 02:32:02 -0300 Subject: Re: [patch] Backtrace prints wrong argument value From: Luis Machado Reply-To: luisgpm@linux.vnet.ibm.com To: Daniel Jacobowitz Cc: gdb-patches@sources.redhat.com In-Reply-To: <20070425191304.GA1283@caradoc.them.org> References: <1177527233.12599.42.camel@localhost> <20070425191304.GA1283@caradoc.them.org> Content-Type: text/plain Date: Wed, 16 May 2007 05:34:00 -0000 Message-Id: <1179293640.4323.16.camel@localhost> Mime-Version: 1.0 X-Mailer: Evolution 2.6.1 Content-Transfer-Encoding: 7bit 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/msg00269.txt.bz2 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. Regards, Luis