From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25090 invoked by alias); 26 Feb 2003 15:57:15 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 25078 invoked from network); 26 Feb 2003 15:57:15 -0000 Received: from unknown (HELO localhost.redhat.com) (172.16.49.200) by 172.16.49.205 with SMTP; 26 Feb 2003 15:57:15 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 915682A9C; Wed, 26 Feb 2003 01:20:45 -0500 (EST) Message-ID: <3E5C5CBD.2030201@redhat.com> Date: Wed, 26 Feb 2003 15:57:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: Re-initializing a list after the control returns to gdb... References: <20030219020101.GI2105@gnat.com> <3E53B97A.4090809@redhat.com> <20030219175056.GP2105@gnat.com> <3E53C88E.90807@redhat.com> <20030219192422.GS2105@gnat.com> <3E53EA7A.8070001@redhat.com> <20030225013722.GM910@gnat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-02/txt/msg00706.txt.bz2 > [Sorry for answering late, got preempted...] > > >> In hindsite, it needs to be converted to an observer model (or a new >> observer model introduced and the current gdb-hooks changed to one of >> the many observers). > > > One model that works extremely well is the signals system implemented in > glib. I find it very nicely done. It would be nice if we could reuse > this, but this is a very very complex machinery doing probably way too > much for what we need in GDB. Yes. GDB just needs a single consistent event mechanism. > I would instead suggest something much more simple, like this: > > enum notice_kinds > { > breakpoint_created_notice, > breakpoint_deleted_notice, > ... > invalid_last_notice, /* Should always be last. */ > }; gdb-events.sh used individual wrapper functions rather than trusting an enum, a void *, and dodgy casts. This was to ensure that the external iterfaces were all strongly typed (calls checked with -Werror) and all nasty casts were burried in the .c file. It did that right. It, however, made several mistakes: - it tried to group all the events together (you've proposed individual registration which is much more incremental) - it didn't implement broadcast (as proposed here) - `event' in GDB has multiple meanings so the name is confusing. So, can you get a prototype observer working for just your ada event (but keep in mind that other events will be boiler-plated)? As for the names, just use the terminology found in the patterns book - observer.[hc]. observer_update_xxx (or notify_xxx), observer_attach_xxx, observer_detach_xxx I think. If GDB needs more than one observer, there's a problem. (oh, unless you've an immediate need for that data/context parameter, i'd leave it out - such a mechanis can be left to the person that actually needs) (shh, doco - but I have a cunning plan - see my recent post about revamping gdbarch.sh into doc/gdbarch.texi). Andrew