From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 422 invoked by alias); 25 Apr 2007 19:45:36 -0000 Received: (qmail 413 invoked by uid 22791); 25 Apr 2007 19:45:35 -0000 X-Spam-Check-By: sourceware.org Received: from igw1.br.ibm.com (HELO igw1.br.ibm.com) (32.104.18.24) by sourceware.org (qpsmtpd/0.31) with ESMTP; Wed, 25 Apr 2007 20:45:33 +0100 Received: from mailhub1.br.ibm.com (mailhub1 [9.18.232.109]) by igw1.br.ibm.com (Postfix) with ESMTP id 2DE4A14824A for ; Wed, 25 Apr 2007 16:34:57 -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 l3PJj8GF1331332 for ; Wed, 25 Apr 2007 16:45:27 -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 l3PJi3CU004443 for ; Wed, 25 Apr 2007 16:44:03 -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 l3PJi1Uj004399; Wed, 25 Apr 2007 16:44:03 -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, 25 Apr 2007 22:28:00 -0000 Message-Id: <1177530305.12599.59.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-04/txt/msg00346.txt.bz2 > What is the corresponding code and debug info? This is the complete GDB log: (gdb) start Breakpoint 1 at 0x10000600: file pr28136.c, line 18. Starting program: /home/luis/binaries/pr28136-64 main () at pr.c:18 18 x = 13; (gdb) s During symbol reading, incomplete CFI data; unspecified registers (e.g., r0) at 0x10000600. 19 y = 14; (gdb) s 20 return (int)gen_movsd (&x, &y); (gdb) gen_movsd (operand0=0xfffff80cb20, operand1=0xfffff80cb24) at pr.c:11 11 return *start_sequence(operand0, operand1); (gdb) 0x00000000100005b0 in start_sequence (x=, y=0xfffff80cb24) at pr.c:6 6 }; (gdb) bt #0 0x00000000100005b0 in start_sequence (x=, y=0xfffff80cb24) at pr.c:6 #1 0x00000000100005d0 in gen_movsd (operand0=0xdeadbeef, operand1=0xfffff80cb24) at pr.c:11 #2 0x0000000010000618 in main () at pr.c:20 (gdb) s gen_movsd (operand0=, operand1=) at pr.c:12 12 } (gdb) > I guess you have debugging information which says that operand0 is > valid on the call instruction and invalid after it. That's the case, "operand0" is valid from low to high where: low: 0x100005c0 high: 0x100005d0 After that range (including 0x100005d0), "operand0" is invalid, just like "operand1". The same happens with "X" from "start_sequence". X is just valid from 0x100005a0 to 0x100005a4. > 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 > So the whole purpose of the decrement is to maintain the PC inside the code block of the function that has called a more inner frame function. It makes sense now. Thanks. > 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. DWARF does seem to lack precision in this case. In order to keep values consistent throughout all the program's execution, how would we manage that? It might confuse people debugging their binaries and facing a different value on backtrace than it is expected. It looks like getting the PC back to its original value (after the function call) would be a good thing since it's desirable that GDB displays no value at all instead of incorrect ones. Best regards, Luis