From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30507 invoked by alias); 26 Aug 2012 18:22:08 -0000 Received: (qmail 30499 invoked by uid 22791); 26 Aug 2012 18:22:07 -0000 X-SWARE-Spam-Status: No, hits=-6.4 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,RCVD_IN_DNSWL_HI,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD,SPF_HELO_PASS X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sun, 26 Aug 2012 18:21:33 +0000 Received: from int-mx01.intmail.prod.int.phx2.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id q7QILTwh018116 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 26 Aug 2012 14:21:32 -0400 Received: from host2.jankratochvil.net (ovpn-116-33.ams2.redhat.com [10.36.116.33]) by int-mx01.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id q7QHIfaV003480 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Sun, 26 Aug 2012 13:18:44 -0400 Date: Sun, 26 Aug 2012 18:22:00 -0000 From: Jan Kratochvil To: Andrew Burgess Cc: "gdb-patches@sourceware.org" Subject: Re: PATCH: error reading variable: value has been optimized out Message-ID: <20120826171840.GA21205@host2.jankratochvil.net> References: <50376F3B.1080407@broadcom.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <50376F3B.1080407@broadcom.com> User-Agent: Mutt/1.5.21 (2010-09-15) 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: 2012-08/txt/msg00787.txt.bz2 On Fri, 24 Aug 2012 14:10:35 +0200, Andrew Burgess wrote: > Looking through, value.c is seems there might also support for having values > partially optimised out, this would seem like a better solution, but I'm not > sure the right way to hook this in, if anyone would like to offer > suggestions I'm happy to create a new patch, alternatively, this could be > improved on later... GDB supports partially unavailable values from partially stored traces. This is AFAIK not applicable for partially optimized out values. #0 0x0000000000400524 in function () #1 0x000000000040051c in broken (operand0=, operand0@entry=1, [...]) at bad.c:10 #2 0x0000000000400415 in main () at main.c:4 The problem is not normally visible because this reproducer comes from old GCC: .ident "GCC: (GNU) 4.2.1" (gdb) info addr operand0 Symbol "operand0" is multi-location: Range 0x400510-0x40051c: a variable in $rdi (gdb) disass [...] 0x0000000000400517 <+7>: callq 0x400524 => 0x000000000040051c <+12>: nop That is here it says 'operand0' is valid in all caller instructions till and including 0x40051b (but not including 0x40051c). This means that 'operand0' would be valid in $rdi even when the CPU already executes arbitrary 'function' instructions which have right to clobber callee-clobbered registers. This is incorrect from GCC. Callee here undefines the value of %rdi for unwind, unaware why, this is normally assumed as %rdi is callee-clobbered register. 00000038 00000014 ffffffff CIE DW_CFA_def_cfa: r7 (rsp) ofs 8 DW_CFA_offset: r16 (rip) at cfa-8 DW_CFA_undefined: r4 (rsi) DW_CFA_undefined: r5 (rdi) 00000050 0000001c 00000038 FDE cie=00000038 pc=00400524..00400531 ^^^^^^^^ Newer GCCs do not say anything is in callee-clobberred register when inside the call, being more correct and making it easier for GDB: GNU C 4.7.1 20120720 (Red Hat 4.7.1-5) -mtune=generic -march=x86-64 -g -O2 -fno-var-tracking-assignments #0 f () at 67.c:4 #1 0x0000000000400515 in g (x=) at 67.c:10 at frame #1: (gdb) info addr x Symbol "x" is multi-location: Range 0x400510-0x400514: a variable in $rdi Dump of assembler code for function g: 0x0000000000400510 <+0>: callq 0x400500 => 0x0000000000400515 <+5>: xor %eax,%eax Here you can see 'x' is valid till and including 0x400513 (that is before 'callq' is executed) but when 'callq' is executing (0x400514) then 'x' is already . So GDB does not try to unwind such value. I agree with the fix but it should have GDB-testsuite compatible testcase. Also FYI it is only for backward compatibility with old GCCs. Thanks, Jan