From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26800 invoked by alias); 19 Sep 2013 16:58:41 -0000 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 Received: (qmail 26789 invoked by uid 89); 19 Sep 2013 16:58:41 -0000 Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 19 Sep 2013 16:58:41 +0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.0 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r8JGwaTB002587 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Thu, 19 Sep 2013 12:58:36 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r8JGwYqT009089; Thu, 19 Sep 2013 12:58:35 -0400 Message-ID: <523B2D39.8060303@redhat.com> Date: Thu, 19 Sep 2013 16:58:00 -0000 From: Pedro Alves User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130625 Thunderbird/17.0.7 MIME-Version: 1.0 To: Eli Zaretskii CC: Mark Kettenis , aburgess@broadcom.com, gdb-patches@sourceware.org Subject: Re: [PATCH+DOC] Print registers not saved in the frame as "", instead of "". References: <5200F55E.2050308@broadcom.com> <201308061318.r76DIMdd016369@glazunov.sibelius.xs4all.nl> <5200FECF.7030304@broadcom.com> <201308061541.r76FfYQN022875@glazunov.sibelius.xs4all.nl> <520142D9.4030304@redhat.com> <5208E3C8.7060107@broadcom.com> <5208E938.3080305@redhat.com> <201308122001.r7CK1862007934@glazunov.sibelius.xs4all.nl> <520E7255.7080206@redhat.com> <5211F25A.5070907@broadcom.com> <5228B15F.7060108@redhat.com> <5228B2D8.7060604@broadcom.com> <5237567C.8050406@redhat.com> <5239B2D8.4030403@broadcom.com> <5239CCB3.605@redhat.com> <83zjram6sw.fsf@gnu.org> <201309182047.r8IKlOGA010471@glazunov.sibelius.xs4all.nl> <83fvt1mems.fsf@gnu.org> In-Reply-To: <83fvt1mems.fsf@gnu.org> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-09/txt/msg00692.txt.bz2 On 09/19/2013 08:53 AM, Eli Zaretskii wrote: >> Date: Wed, 18 Sep 2013 22:47:24 +0200 (CEST) >> From: Mark Kettenis >> CC: palves@redhat.com, aburgess@broadcom.com, gdb-patches@sourceware.org, >> mark.kettenis@xs4all.nl >> >>> Date: Wed, 18 Sep 2013 19:30:07 +0300 >>> From: Eli Zaretskii >>> >>> Also, shouldn't we mention optimizations as (the main) reason for >>> registers being unavailable? >> >> I don't consider optimisations as an important cause of registers not >> being saved. > > The question is: does it happen in practice? If it does, I think we > should mention that, because it's important to let the users know that > recompiling without optimizations might remove this nuisance. I think it's really independent of optimization. Jan's comments at help understand this. Current/recent enough GCC doesn't mark variables/arguments as being in call-clobbered registers in the ranges corresponding to function calls, while older GCCs did. Newer GCCs will just not say where the variable is, so GDB will end up realizing the variable is optimized out. In fact, if I build an -O2 version of GDB, and do $ readelf --debug-dump=frames ./gdb | grep DW_CFA_undefined nothing comes out. Now, GDB itself could just assume that call-clobbered registers are always in frames other than the innermost, but that'll be not very user friendly, I think. Perhaps... we should completely toss out this patch, and go the other way around. When printing registers of an outer frame, ignore DW_CFA_undefined, and read the registers from the inner frame anyway... IOW, define the values of call-clobbered registers in outer frames as "the values the registers would have if the inner frame returned _now_". Mark, what do you think? (I didn't try implementing that, but I think that'll just mean ignoring the optimized_out flag when dumping registers (but not when printing variables marked as living in "optimized out" registers). I wondered what would the "return" command do if forcing a return to a function where we current show registers as "/", to see if that would through a "value optimized out" error or some such. It actually doesn't: Breakpoint 2, stop_frame () at dw2-reg-undefined.c:22 22 in dw2-reg-undefined.c (gdb) info registers rax 0x0 0 rbx 0x0 0 rcx 0x400552 4195666 rdx 0x7fffffffdb18 140737488345880 rsi 0x7fffffffdb08 140737488345864 rdi 0x1 1 rbp 0x7fffffffda00 0x7fffffffda00 rsp 0x7fffffffda00 0x7fffffffda00 r8 0x323d7b1f40 215779843904 r9 0x323d00f310 215771837200 r10 0x7fffffffd880 140737488345216 r11 0x323d421640 215776106048 r12 0x400430 4195376 r13 0x7fffffffdb00 140737488345856 r14 0x0 0 r15 0x0 0 rip 0x400540 0x400540 eflags 0x246 [ PF ZF IF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) up #1 0x0000000000400550 in first_frame () at dw2-reg-undefined.c:27 27 in dw2-reg-undefined.c (gdb) info registers rax rbx rcx rdx rsi rdi rbp 0x7fffffffda10 0x7fffffffda10 rsp r8 0x323d7b1f40 215779843904 r9 0x323d00f310 215771837200 r10 0x7fffffffd880 140737488345216 r11 0x323d421640 215776106048 r12 0x400430 4195376 r13 0x7fffffffdb00 140737488345856 r14 0x0 0 r15 0x0 0 rip 0x400550 0x400550 eflags 0x246 [ PF ZF IF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) down #0 stop_frame () at dw2-reg-undefined.c:22 22 in dw2-reg-undefined.c (gdb) return Make stop_frame return now? (y or n) y #0 first_frame () at dw2-reg-undefined.c:28 28 in dw2-reg-undefined.c (gdb) info registers rax 0x0 0 rbx 0x0 0 rcx 0x400552 4195666 rdx 0x7fffffffdb18 140737488345880 rsi 0x7fffffffdb08 140737488345864 rdi 0x1 1 rbp 0x7fffffffda10 0x7fffffffda10 rsp 0x7fffffffda00 0x7fffffffda00 r8 0x323d7b1f40 215779843904 r9 0x323d00f310 215771837200 r10 0x7fffffffd880 140737488345216 r11 0x323d421640 215776106048 r12 0x400430 4195376 r13 0x7fffffffdb00 140737488345856 r14 0x0 0 r15 0x0 0 rip 0x400550 0x400550 eflags 0x246 [ PF ZF IF ] cs 0x33 51 ss 0x2b 43 ds 0x0 0 es 0x0 0 fs 0x0 0 gs 0x0 0 (gdb) In case that isn't clear, GDB did fetch the values of call-clobbered registers from the inner frame. I didn't check where/how that happens. -- Pedro Alves