From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3778 invoked by alias); 7 Aug 2013 14:41:13 -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 3751 invoked by uid 89); 7 Aug 2013 14:41:12 -0000 X-Spam-SWARE-Status: No, score=-1.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KHOP_THREADED,RCVD_IN_DNSWL_LOW,RCVD_IN_HOSTKARMA_YE,RDNS_NONE,SPF_PASS autolearn=ham version=3.3.1 Received: from Unknown (HELO mail-ob0-f179.google.com) (209.85.214.179) by sourceware.org (qpsmtpd/0.84/v0.84-167-ge50287c) with ESMTP; Wed, 07 Aug 2013 14:41:11 +0000 Received: by mail-ob0-f179.google.com with SMTP id fb19so3715049obc.24 for ; Wed, 07 Aug 2013 07:41:03 -0700 (PDT) MIME-Version: 1.0 X-Received: by 10.182.246.232 with SMTP id xz8mr2865569obc.9.1375886463857; Wed, 07 Aug 2013 07:41:03 -0700 (PDT) Received: by 10.182.125.70 with HTTP; Wed, 7 Aug 2013 07:41:03 -0700 (PDT) In-Reply-To: <87k3k7kbdy.fsf@fleche.redhat.com> References: <51CDBD48.6010903@gmail.com> <87k3k7kbdy.fsf@fleche.redhat.com> Date: Wed, 07 Aug 2013 14:41:00 -0000 Message-ID: Subject: Re: Events when inferior is modified From: Nick Bull To: Tom Tromey Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-SW-Source: 2013-08/txt/msg00198.txt.bz2 Tom, Thanks for your comments: I'll modify and resubmit. On 30 July 2013 22:04, Tom Tromey wrote: > > I'm curious to know why you wanted pre- and post-observers for inferior > calls, but not anything else. [...] > > It seem to me that this may just be an approximation of "dirty" in the > remote case. E.g., gdbserver may write a breakpoint and otherwise > modify things without notifying gdb. > > On the other hand, maybe you want to rule out breakpoints from being > considered "dirty". But then the change has to be more complicated in > another way. The sense of "dirty" that I'm using is "the user has interfered with program state", and not for example "gdb has some cached data which is now stale". For context, I'm using this patch in a system with a lot of Python scripting around gdb to support the user in various ways. I'm also only concerned with the remote gdbserver case, should that be relevant. The motivation behind this work is that the user, sitting at the gdb command line trying to debug their program, has the ability to modify the program's state under its feet and hence change its future behaviour. Which is potentially useful in exploring fixes without recompiling, but carries the risk that you leave a change in and carry on, forgetting that you're not debugging the real system any more. I don't want to totally prevent that kind of modification, but I do want to know that it has happened. Various UI options are possible at that point, such as emitting warnings, changing the prompt etc, but those choices can all be made in the scripting layer. Breakpoints aren't a modification for these purposes, as they don't cause the debugged program to generate different results. Well, I hope not. Inferior function calls are useful in conditional breakpoints and for interrogating data structures, but sometimes they perturb the program state and sometimes they don't. Ignoring the synthesized stack frame on which they were called, of course. By receiving observer events before and after the call, we can work behind the user's back to check for differences. Again, what we do about that---issuing a warning, or maybe even reverting the changes---can be decided at a higher level. Picking up changes to registers and memory is a bonus feature for me, rather than essential, as it's an explicit choice to change state whereas a fn call may just read state. And per Pedro's comment, other ways to modify program state are possible, but haven't tripped me up yet; so in that respect the itch is sufficiently scratched for now. Nick