This is the mail archive of the
mailing list for the GDB project.
Re: [PATCH] gdb: New frame_cache_cleared observer.
- From: Doug Evans <dje at google dot com>
- To: Andrew Burgess <andrew dot burgess at embecosm dot com>
- Cc: Pedro Alves <palves at redhat dot com>, gdb-patches <gdb-patches at sourceware dot org>
- Date: Mon, 30 Mar 2015 11:51:25 -0700
- Subject: Re: [PATCH] gdb: New frame_cache_cleared observer.
- Authentication-results: sourceware.org; auth=none
- References: <1427303468-17834-1-git-send-email-andrew dot burgess at embecosm dot com> <CADPb22TsxSy8d8dstV5HPz6gU-Nbf=sKoyVXFHcR5VNTdXB3Zg at mail dot gmail dot com> <5513D04B dot 1070602 at redhat dot com> <20150326125012 dot GB11596 at embecosm dot com>
On Thu, Mar 26, 2015 at 5:50 AM, Andrew Burgess
> Doug, Pedro,
> * Pedro Alves <email@example.com> [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
>> > <firstname.lastname@example.org> 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 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
> Thanks for your time,
>  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:
Last review cycle begins here:
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