From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22081 invoked by alias); 19 Aug 2013 10:25:05 -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 22063 invoked by uid 89); 19 Aug 2013 10:25:05 -0000 X-Spam-SWARE-Status: No, score=-5.9 required=5.0 tests=AWL,BAYES_00,KHOP_RCVD_UNTRUST,KHOP_THREADED,RCVD_IN_DNSWL_MED,RCVD_IN_HOSTKARMA_W,RP_MATCHES_RCVD autolearn=ham version=3.3.2 Received: from mms1.broadcom.com (HELO mms1.broadcom.com) (216.31.210.17) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Mon, 19 Aug 2013 10:24:36 +0000 Received: from [10.9.208.57] by mms1.broadcom.com with ESMTP (Broadcom SMTP Relay (Email Firewall v6.5)); Mon, 19 Aug 2013 03:20:35 -0700 X-Server-Uuid: 06151B78-6688-425E-9DE2-57CB27892261 Received: from IRVEXCHSMTP3.corp.ad.broadcom.com (10.9.207.53) by IRVEXCHCAS08.corp.ad.broadcom.com (10.9.208.57) with Microsoft SMTP Server (TLS) id 14.1.438.0; Mon, 19 Aug 2013 03:24:27 -0700 Received: from mail-irva-13.broadcom.com (10.10.10.20) by IRVEXCHSMTP3.corp.ad.broadcom.com (10.9.207.53) with Microsoft SMTP Server id 14.1.438.0; Mon, 19 Aug 2013 03:24:27 -0700 Received: from [10.177.73.49] (unknown [10.177.73.49]) by mail-irva-13.broadcom.com (Postfix) with ESMTP id CE405F2D73; Mon, 19 Aug 2013 03:24:26 -0700 (PDT) Message-ID: <5211F25A.5070907@broadcom.com> Date: Mon, 19 Aug 2013 10:25:00 -0000 From: "Andrew Burgess" User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:17.0) Gecko/20130801 Thunderbird/17.0.8 MIME-Version: 1.0 To: gdb-patches@sourceware.org cc: "Pedro Alves" , "Mark Kettenis" 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> <520142D9.4030304@redhat.com> <5208E3C8.7060107@broadcom.com> <5208E938.3080305@redhat.com> <201308122001.r7CK1862007934@glazunov.sibelius.xs4all.nl> <520E7255.7080206@redhat.com> In-Reply-To: <520E7255.7080206@redhat.com> Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 7bit X-SW-Source: 2013-08/txt/msg00496.txt.bz2 On 16/08/2013 7:41 PM, Pedro Alves wrote: > On 08/12/2013 09:01 PM, Mark Kettenis wrote: >>> Date: Mon, 12 Aug 2013 14:55:04 +0100 >>> From: Pedro Alves >>> >>> On 08/12/2013 02:31 PM, Andrew Burgess wrote: >>>> On 06/08/2013 7:39 PM, Pedro Alves wrote: >>>>> 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. >>>> >>>> Given almost a week has passed with no further feedback I plan to >>>> commit this patch tomorrow unless there's any further discussion to be had. >>> >>> TBC, note my opinion doesn't get to overrule Mark's. Consensus >>> works much better, and Mark does have deep knowledge of all >>> ABI/pseudo registers/etc. gdb things. >>> That said, Mark, if you still disagree, please counter argue, >>> otherwise, we'll just have to assume you do agree with the >>> rationales and clarifications. >> >> Can't say I agree. It simply doesn't make sense for registers to be >> "optimized out". I guess there are two reasons why GDB can't display >> the contents of a register in a frame: >> >> 1. The register contents aren't made available by the debugging >> interface, i.e. ptrace(2) or the remote stub doesn't tell us. >> >> 2. The register wasn't saved before calling another function. >> >> I guess after Andrew's chnages 1) would be shown as and >> 2) would become . But in the latter case something >> like would make more sense. >> >> That said, Pedro, you're pretty much the expert for this area of GDB. >> So If you think Andrew should go ahead with this, feel free to ignore >> me. > > This is a tough call. I do agree that "optimized out" for registers > is a bit confusing. However, we already do print "" in > other places, such as when printing expressions, and consistency > is good. If we did add a distinction, I agree with Andrew that it should > be done in a more systematic way. However, I'm not really sure we need > much machinery. Wouldn't something like: > > void > val_print_optimized_out (const struct value *val, struct ui_file *stream) > { > if (value_lval_const (val) == lval_register) > fprintf_filtered (stream, _("")); > else > fprintf_filtered (stream, _("")); > } > > work? What could be the register value cases that would print > "not saved" that we'd still want to print "optimized out" ? The only case I can immediately think of where this would cause a problem would be for computed locations, (lval_computed). The easy answer would be (in that case) the blame the compiler - why say the location is in a register if that register is volatile - but sadly I see this way too often. However, exchanging what I see as the current larger inconsistency, for this much smaller one seems like a good deal to me, especially if it gets this patch unblocked... Thanks, Andrew