From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16171 invoked by alias); 6 Aug 2013 16:02:22 -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 16143 invoked by uid 89); 6 Aug 2013 16:02: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 mms3.broadcom.com) (216.31.210.19) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 06 Aug 2013 16:02:20 +0000 Received: from [10.9.208.53] by mms3.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Tue, 06 Aug 2013 08:52:06 -0700 X-Server-Uuid: B86B6450-0931-4310-942E-F00ED04CA7AF Received: from IRVEXCHSMTP1.corp.ad.broadcom.com (10.9.207.51) by IRVEXCHCAS06.corp.ad.broadcom.com (10.9.208.53) with Microsoft SMTP Server (TLS) id 14.1.438.0; Tue, 6 Aug 2013 09:02:01 -0700 Received: from mail-irva-13.broadcom.com (10.10.10.20) by IRVEXCHSMTP1.corp.ad.broadcom.com (10.9.207.51) with Microsoft SMTP Server id 14.1.438.0; Tue, 6 Aug 2013 09:02:01 -0700 Received: from [10.177.73.61] (unknown [10.177.73.61]) by mail-irva-13.broadcom.com (Postfix) with ESMTP id 2255AF2D75; Tue, 6 Aug 2013 09:02:00 -0700 (PDT) Message-ID: <52011DF8.3050102@broadcom.com> Date: Tue, 06 Aug 2013 16:02: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> <5200FECF.7030304@broadcom.com> <201308061541.r76FfYQN022875@glazunov.sibelius.xs4all.nl> In-Reply-To: <201308061541.r76FfYQN022875@glazunov.sibelius.xs4all.nl> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-08/txt/msg00176.txt.bz2 On 06/08/2013 4:41 PM, Mark Kettenis wrote: >> Date: Tue, 6 Aug 2013 14:49:03 +0100 >> From: "Andrew Burgess" >> >> 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? > > I think that registers are either available or unavailble. If I understand correctly you're talking here not about how gdb represents registers, but registers in a "real" sense. I'm not sure I agree with your sentence, I guess it depends on your exact definition of "unavailable", clearly optimized out could be a sub-set of unavailable. > A register > being unavailble implies that a variable that is supposed to live in > such a register may have been optimized out. I agree with this. > Whether GDB's pseudo > variables that respresent registers are considered unavailable or > optimized out in that case is arguable. I don't really understand what "that case" is referring too, nor what "pseudo variables" are. We can consider different cases, for example, a request for a program variable that has been stored in a register that is not preserved over an ABI call, this will create a gdb value object with a location of the specified register, and attempt to fetch the register will then mark the value as (in the example I've already cited) optimized out. Similarly, a direct request to gdb for the specified register would result in a value that is marked optimiszed out. I've only given as an example the DWARF unwinder, I guess other unwinders could handle registers lost over a call differently and mark them as unavailable, however, I'm not aware of any that do this, though I've not looked that hard, can you give an example? Also I thought, though I could be wrong on this, that the gdb value "unavailable" was currently only used for value content that had not been collected through tracing, though I believe there are a few places, such as the one I'm patching here, where the value "unavailable" state is being set incorrectly. Do you have any examples of how the gdb value "unavailable" state is intentionally used for something other than non-collected trace content? I think you're suggesting that the use of optimized out as a way to mark registers lost due to the call ABI is wrong, and though I can see how having a separate state for this, or maybe using unavailable, might be a good thing it's certainly not what this patch is about, nor do I think this patch is a step away from that, if that is indeed a goal for gdb, even after my patch, if a value is marked unavailable rather than optimized out, it will be displayed as unavailable. Thanks, Andrew