From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19828 invoked by alias); 25 Apr 2007 19:13:14 -0000 Received: (qmail 19820 invoked by uid 22791); 25 Apr 2007 19:13:13 -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, 25 Apr 2007 20:13:10 +0100 Received: from return.false.org (localhost [127.0.0.1]) by return.false.org (Postfix) with ESMTP id 3DE104B267; Wed, 25 Apr 2007 14:13:09 -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 CC9DC4B262; Wed, 25 Apr 2007 14:13:04 -0500 (CDT) Received: from drow by caradoc.them.org with local (Exim 4.67) (envelope-from ) id 1HgmvI-0000UX-6I; Wed, 25 Apr 2007 15:13:04 -0400 Date: Wed, 25 Apr 2007 19:25:00 -0000 From: Daniel Jacobowitz To: Luis Machado Cc: gdb-patches@sources.redhat.com Subject: Re: [patch] Backtrace prints wrong argument value Message-ID: <20070425191304.GA1283@caradoc.them.org> Mail-Followup-To: Luis Machado , gdb-patches@sources.redhat.com References: <1177527233.12599.42.camel@localhost> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1177527233.12599.42.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-04/txt/msg00344.txt.bz2 On Wed, Apr 25, 2007 at 03:53:53PM -0300, Luis Machado wrote: > If we call a backtrace on GDB, that's what we have: > > #0 - start_sequence (x=, y=0xfffff9b1b34) > #1 - gen_movsd (operand0=0xdeadbeef, operand1=0xfffff9b1b34) > > Notice that on frame #1, "operand0" has a "0xdeadbeef" value, which > happens to be the return value from the "start_sequence" function from > frame #0. This is clearly incorrect. What is the corresponding code and debug info? I guess you have debugging information which says that operand0 is valid on the call instruction and invalid after it. > What is causing this incorrect value to be printed on frame levels above > 0 is an adjustment to the PC on the "frame_unwind_address_in_block" > function. The purpose of this adjustment to PC is to make it point to > the branch instruction rather than the instruction right after the > branch instruction ( this is achieved with a --pc decrement). You've partly misunderstood the purpose of the decrement. We never look at the branch instruction; it's to make sure that the PC points to the same function as the call instruction, in the case of a function that ends in a call to abort. Having it point to the middle of an instruction is perfectly fine. Consider this code: func1: copy arg1 to r20 call abort func2: copy arg2 to r3 call func1 return 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. -- Daniel Jacobowitz CodeSourcery