From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25320 invoked by alias); 6 Aug 2013 13:49:23 -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 25307 invoked by uid 89); 6 Aug 2013 13:49:22 -0000 X-Spam-SWARE-Status: No, score=-3.9 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_MED,RCVD_IN_HOSTKARMA_W,RDNS_NONE autolearn=ham version=3.3.1 Received: from Unknown (HELO mms1.broadcom.com) (216.31.210.17) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 06 Aug 2013 13:49:21 +0000 Received: from [10.9.208.55] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 06 Aug 2013 06:45:14 -0700 X-Server-Uuid: 06151B78-6688-425E-9DE2-57CB27892261 Received: from IRVEXCHSMTP2.corp.ad.broadcom.com (10.9.207.52) by IRVEXCHCAS07.corp.ad.broadcom.com (10.9.208.55) with Microsoft SMTP Server (TLS) id 14.1.438.0; Tue, 6 Aug 2013 06:49:04 -0700 Received: from mail-irva-13.broadcom.com (10.10.10.20) by IRVEXCHSMTP2.corp.ad.broadcom.com (10.9.207.52) with Microsoft SMTP Server id 14.1.438.0; Tue, 6 Aug 2013 06:49:05 -0700 Received: from [10.177.73.61] (unknown [10.177.73.61]) by mail-irva-13.broadcom.com (Postfix) with ESMTP id 68282F2D74; Tue, 6 Aug 2013 06:49:04 -0700 (PDT) Message-ID: <5200FECF.7030304@broadcom.com> Date: Tue, 06 Aug 2013 13:49:00 -0000 From: "Andrew Burgess" User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130620 Thunderbird/17.0.7 MIME-Version: 1.0 To: "Mark Kettenis" cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Consistent display of "" References: <5200F55E.2050308@broadcom.com> <201308061318.r76DIMdd016369@glazunov.sibelius.xs4all.nl> In-Reply-To: <201308061318.r76DIMdd016369@glazunov.sibelius.xs4all.nl> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-08/txt/msg00173.txt.bz2 On 06/08/2013 2:18 PM, Mark Kettenis wrote: >> Date: Tue, 6 Aug 2013 14:08:46 +0100 >> From: "Andrew Burgess" >> >> In some cases we report optimized out registers as "*value not available*" >> rather than "", the patch below makes this more consistent >> in the case I've spotted. >> >> Here's an example: >> >> (gdb) up >> #1 0x0000000000400800 in first_frame () at dw2-reg-undefined.c:27 >> 27 in dw2-reg-undefined.c >> (gdb) info registers rax >> rax *value not available* >> (gdb) p/x $rax >> $1 = >> >> After the patch the behaviour is now: >> >> (gdb) up >> #1 0x0000000000400800 in first_frame () at dw2-reg-undefined.c:27 >> 27 in dw2-reg-undefined.c >> (gdb) info registers rax >> rax >> (gdb) p/x $rax >> $1 = >> >> The behaviour for values that are unavailable is currently unchanged, >> though I have a follow up patch for this too. >> >> OK to apply? > > I'd say no. There is a difference between "unavailable" and > "optimized out". Registers will be unavailable even if you compile > without any optimization, because the ABI specifies that their > contents are not saved across function calls. So "optimized out" > makes very little sense for registers. I disagree for 3 reasons. 1. This patch is about consistency, having "print " report one thing and "info register " report another seems like a bad thing to me. 2. We previously fetched the register by calling deprecated_frame_register_read, this eventually gets a value object by called frame_unwind_register_value, we then extract the unavailable and optimized-out attributes from the value object and for no good reason I can see create a new value object and mark it as unavailable. My patch side-steps this middle ground of calling deprecated_frame_register_read, and instead works with the value we get back by reading the register, this is already marked optimized out. My interpretation of your concern would be that you don't think it /should/ be marked as optimized out, I believe however, that this is not really an issue for this patch, if this changes later then we'd revert back to printing unavailable rather than optimized out, my patch doesn't prevent that, it just prints the real state of the value object. 3. My understanding was that values lost due to the ABI of a call site were recorded as optimized out. For evidence I would present dwarf2_frame_prev_register, and how DWARF2_FRAME_REG_UNDEFINED is handled. For these reasons I believe my patch should still be considered, what do you think? Thanks, Andrew