From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 126175 invoked by alias); 30 Mar 2015 18:51:31 -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 126163 invoked by uid 89); 30 Mar 2015 18:51:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,SPF_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 X-HELO: mail-ob0-f178.google.com Received: from mail-ob0-f178.google.com (HELO mail-ob0-f178.google.com) (209.85.214.178) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Mon, 30 Mar 2015 18:51:28 +0000 Received: by obvd1 with SMTP id d1so69289971obv.0 for ; Mon, 30 Mar 2015 11:51:27 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=lR7gU1GHsQYJ3L1hsoaVxW4VA4Md9tDCY8DDQtM9Ou0=; b=T22VY6lylxan6Bkh8MoYlLK1q5fTrGnvgxy4D24+DZ/jCcpPCSlUb4FNONSNUNds9N ukFrsivCjMLSdnTDxXF/lfp024VUcX2W9HEHVW3OueTpK1JpQWrh06q/jq7+Eo7BSqXG A0GOfxDwTXH4cETETicUcL+EsN/B48JJ0jnzf20VtzDH7badMSLKJSshqUMMuqp/PoqB OqlhgSAVp/i83ynaSnziJuee/mnZAH0bu2/Jeai+8wZlIQhk7I3DSB+3ymykVUCjQbgi w8ISp038qAxUNBwC5tdP4C4eg/7m0iuQRonQz39XZorhk6DfLT5qx56PKRc5Dtwq8dx7 MLAg== X-Gm-Message-State: ALoCoQncjLX4JIHvCr4kVqc34qMqaFLuZEJ2f8TO2y/kn/GSv21y194TlutLEkaeLNGzctc9m6QX MIME-Version: 1.0 X-Received: by 10.60.45.165 with SMTP id o5mr28524461oem.44.1427741485757; Mon, 30 Mar 2015 11:51:25 -0700 (PDT) Received: by 10.182.142.226 with HTTP; Mon, 30 Mar 2015 11:51:25 -0700 (PDT) In-Reply-To: <20150326125012.GB11596@embecosm.com> References: <1427303468-17834-1-git-send-email-andrew.burgess@embecosm.com> <5513D04B.1070602@redhat.com> <20150326125012.GB11596@embecosm.com> Date: Mon, 30 Mar 2015 18:51:00 -0000 Message-ID: Subject: Re: [PATCH] gdb: New frame_cache_cleared observer. From: Doug Evans To: Andrew Burgess Cc: Pedro Alves , gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2015-03/txt/msg01010.txt.bz2 On Thu, Mar 26, 2015 at 5:50 AM, Andrew Burgess wrote: > Doug, Pedro, > > * Pedro Alves [2015-03-26 09:24:27 +0000]: > >> On 03/25/2015 11:18 PM, Doug Evans wrote: >> > On Wed, Mar 25, 2015 at 10:11 AM, Andrew Burgess >> > wrote: >> >> This adds a new observer for the frame cache cleared event. >> >> >> >> While working on a new gdb port I found that I wanted to cache machine >> >> state that was gathered as part of the register read process. The >> >> most appropriate time to discard this cached information is when the >> >> frame cache is flushed. >> >> >> >> However, as I don't have an actual use for this observer that I can >> >> post upstream (yet) I don't know if this will be acceptable, but given >> >> it's a fairly small change I thought I'd try. > >> Right. We delete dead code all the time. So it's better to wait until >> is has a use, because otherwise someone could well end up stumbling on it, >> noticing it has no uses and decides to send a patch that garbage >> collects it. > > Thanks for looking at my patch, and I understand why you've rejected > it for now. It's easy enough to prevent people errantly spending cycles submitting a patch to delete such code. I think the larger worry is how long will the code stay in the yet-to-be-used state, and how does one manage things as the quantity of such code grows. IOW, can we manage opening the gates without it turning into a flood? It's just easier to keep the gate shut. > I do have one followup: as far as I can tell the observers > register_changed, inferior_call_pre, and inferior_call_post are only > used by the python bindings to make the events available in python. > As far as I can tell[1] these event bindings are only used within the > test suite. > > ... and a question: If I made frame_cache_cleared a python accessible > event, and added a test would this be sufficient to keep the code > alive? > > Thanks for your time, > Andrew > > [1] I could easily be wrong! Yeah, they're events exported to python and were added because someone had a need for them from python. Original posting is here: https://sourceware.org/ml/gdb-patches/2013-06/msg00889.html Last review cycle begins here: https://sourceware.org/ml/gdb-patches/2014-10/msg00573.html That they're only used by the testsuite is typical of most of python support: It's there for users writing python scripts, gdb itself doesn't use it. If a good use-case can be made for python wanting to know when the frame-cache is cleared then I'd support such a patch. OTOH, I'm wondering if a frame-cache-cleared event is the right one for your use-case. I'm guessing this isn't for frame unwinding, otherwise you could just use the existing mechanism (e.g., frame_unwind.dealloc_cache).