From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23342 invoked by alias); 1 Dec 2013 15:23:56 -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 23210 invoked by uid 89); 1 Dec 2013 15:23:55 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.2 required=5.0 tests=AWL,BAYES_20,FREEMAIL_FROM,RDNS_NONE,SPF_PASS autolearn=no version=3.3.2 X-HELO: mail-oa0-f43.google.com Received: from Unknown (HELO mail-oa0-f43.google.com) (209.85.219.43) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Sun, 01 Dec 2013 15:23:55 +0000 Received: by mail-oa0-f43.google.com with SMTP id i7so12163633oag.30 for ; Sun, 01 Dec 2013 07:23:46 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.60.146.210 with SMTP id te18mr50811615oeb.20.1385911426833; Sun, 01 Dec 2013 07:23:46 -0800 (PST) Received: by 10.182.158.163 with HTTP; Sun, 1 Dec 2013 07:23:46 -0800 (PST) In-Reply-To: <52931CEC.7040407@redhat.com> References: <51CDBD48.6010903@gmail.com> <87k3k7kbdy.fsf@fleche.redhat.com> <528A0A83.1080203@gmail.com> <52931CEC.7040407@redhat.com> Date: Sun, 01 Dec 2013 15:23:00 -0000 Message-ID: Subject: Re: [PATCH v2] Events when inferior is modified From: Nick Bull To: Phil Muldoon Cc: gdb-patches@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 X-SW-Source: 2013-12/txt/msg00001.txt.bz2 On 25 November 2013 09:48, Phil Muldoon wrote: > On 18/11/13 12:39, Nick Bull wrote: > >> This patch adds new observers, and corresponding Python events, for >> various actions on an inferior: calling a function (by hand), >> modifying registers or modifying memory. > > Thanks just a few nits and some questions. I did not see tests for > these, and also, documentation? In any case, both are needed. Phil, Thanks for looking at this. All the nits make sense, and I'll fix them and add tests. > I'm kind of on the fence about the inferior_altered naming. A lot of > things can alter an inferior which would make this a very broad event > category. Like single stepping I would consider altering the inferior. > > With your memory changed event, would it fire on a breakpoint > insertion? GDB does a lot of installing/uninstalling of breakpoints > behind the scene in the inferior. > > Also, it would be super if we could split up the register > and memory events with read/write events. What do you think? I'm going to revise the memory change event to use the existing memory_changed observer, which I had overlooked because it doesn't have a Python event. It's closer to what I wanted anyway, which is to track only modifications to the program that are made explicitly by the GDB user. Given this I would give it a separate MemoryChangedEvent type so that the name matches the corresponding observer. Then the other events would be RegisterChanged and InferiorCall. I suppose we might want to somehow distinguish that these events are about explicit changes to program state rather than the 'behind-the-scenes' work that GDB does, in case we ever want to create events of the latter type. But I don't have any great suggestions for names just now. Nick