From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3663 invoked by alias); 16 May 2007 15:20:10 -0000 Received: (qmail 3651 invoked by uid 22791); 16 May 2007 15:20:09 -0000 X-Spam-Check-By: sourceware.org Received: from igw3.br.ibm.com (HELO igw3.br.ibm.com) (32.104.18.26) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 16 May 2007 15:20:05 +0000 Received: from mailhub1.br.ibm.com (unknown [9.18.232.109]) by igw3.br.ibm.com (Postfix) with ESMTP id C5D80390115 for ; Wed, 16 May 2007 12:11:20 -0300 (BRT) Received: from d24av02.br.ibm.com (d24av02.br.ibm.com [9.18.232.47]) by mailhub1.br.ibm.com (8.13.8/8.13.8/NCO v8.3) with ESMTP id l4GFJicM1437780 for ; Wed, 16 May 2007 12:19:45 -0300 Received: from d24av02.br.ibm.com (loopback [127.0.0.1]) by d24av02.br.ibm.com (8.12.11.20060308/8.13.3) with ESMTP id l4GFIbqx013262 for ; Wed, 16 May 2007 12:18:38 -0300 Received: from [9.18.238.71] ([9.18.238.71]) by d24av02.br.ibm.com (8.12.11.20060308/8.12.11) with ESMTP id l4GFIZgX013115; Wed, 16 May 2007 12:18:37 -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: <20070516144250.GD24682@caradoc.them.org> References: <1177527233.12599.42.camel@localhost> <20070425191304.GA1283@caradoc.them.org> <1179293640.4323.16.camel@localhost> <20070516144250.GD24682@caradoc.them.org> Content-Type: text/plain Date: Wed, 16 May 2007 15:20:00 -0000 Message-Id: <1179328781.4295.13.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/msg00280.txt.bz2 > 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. In such a case, the debug info would still say that the value is valid and point to the "wrong" place, that's clearly a fault from DWARF's side. > 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. I believe this would be a better solution, but would require changes to other toolchain projects and would surely take time. It could be prohibitive right now. > 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? I'll check this code. Thanks. If there is a way to temporarily store those values that we know for sure that will be wasted during the next inner frame's function execution, we could recover them during backtrace. That could add some complexity to the unwinding procedure though. Regards, Luis