From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13786 invoked by alias); 6 Aug 2013 15:41:48 -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 13761 invoked by uid 89); 6 Aug 2013 15:41:47 -0000 X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RDNS_NONE autolearn=no version=3.3.1 Received: from Unknown (HELO glazunov.sibelius.xs4all.nl) (83.163.83.176) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 06 Aug 2013 15:41:46 +0000 Received: from glazunov.sibelius.xs4all.nl (kettenis@localhost [127.0.0.1]) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3) with ESMTP id r76FfYXe000088; Tue, 6 Aug 2013 17:41:35 +0200 (CEST) Received: (from kettenis@localhost) by glazunov.sibelius.xs4all.nl (8.14.5/8.14.3/Submit) id r76FfYQN022875; Tue, 6 Aug 2013 17:41:34 +0200 (CEST) Date: Tue, 06 Aug 2013 15:41:00 -0000 Message-Id: <201308061541.r76FfYQN022875@glazunov.sibelius.xs4all.nl> From: Mark Kettenis To: aburgess@broadcom.com CC: gdb-patches@sourceware.org In-reply-to: <5200FECF.7030304@broadcom.com> (aburgess@broadcom.com) Subject: Re: [PATCH] Consistent display of "" References: <5200F55E.2050308@broadcom.com> <201308061318.r76DIMdd016369@glazunov.sibelius.xs4all.nl> <5200FECF.7030304@broadcom.com> X-SW-Source: 2013-08/txt/msg00175.txt.bz2 > 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. A register being unavailble implies that a variable that is supposed to live in such a register may have been optimized out. Whether GDB's pseudo variables that respresent registers are considered unavailable or optimized out in that case is arguable.