From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24210 invoked by alias); 6 Aug 2013 18:39:33 -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 24199 invoked by uid 89); 6 Aug 2013 18:39:32 -0000 X-Spam-SWARE-Status: No, score=-6.9 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_HOSTKARMA_W,RCVD_IN_HOSTKARMA_WL,RDNS_NONE,SPF_HELO_PASS,SPF_PASS autolearn=no version=3.3.1 Received: from Unknown (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Tue, 06 Aug 2013 18:39:31 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r76IdNLf009919 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Tue, 6 Aug 2013 14:39:23 -0400 Received: from [127.0.0.1] (ovpn01.gateway.prod.ext.ams2.redhat.com [10.39.146.11]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r76IdLZ7030907; Tue, 6 Aug 2013 14:39:22 -0400 Message-ID: <520142D9.4030304@redhat.com> Date: Tue, 06 Aug 2013 18:39: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: Mark Kettenis CC: aburgess@broadcom.com, 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/msg00180.txt.bz2 On 08/06/2013 04:41 PM, Mark Kettenis wrote: >> Date: Tue, 6 Aug 2013 14:49:03 +0100 >> From: "Andrew Burgess" >> 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. I think improving consistency as in Andrew's patch is good. When values were introduced, this particular "info registers"/"*value not available*" string already existed, and it was never adjusted. The distinction between and is: - means that the object no longer exists in the compiled binary, because the compiler got rid of it (the debug info tells us there's no way to retrieve it). - means that the object was not optimized out, and actually exists in the program (and the debug info describes how to get at it), but we don't have access to the bits necessary to extract/compute the object from -- e.g., a core file section has been truncated, a tracepoint did not collect the necessary registers or memory, etc.. I favor normalizing GDB's output in this direction. -- Pedro Alves