From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11778 invoked by alias); 17 Oct 2006 23:32:27 -0000 Received: (qmail 11770 invoked by uid 22791); 17 Oct 2006 23:32:26 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 17 Oct 2006 23:32:22 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 76FA348CDBF for ; Tue, 17 Oct 2006 19:32:21 -0400 (EDT) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12033-01-3 for ; Tue, 17 Oct 2006 19:32:21 -0400 (EDT) Received: from takamaka.act-europe.fr (joel.gnat.com [205.232.38.116]) by nile.gnat.com (Postfix) with ESMTP id 4094348CD91 for ; Tue, 17 Oct 2006 19:32:21 -0400 (EDT) Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 2FFC147F01; Tue, 17 Oct 2006 19:32:17 -0400 (EDT) Date: Tue, 17 Oct 2006 23:32:00 -0000 From: Joel Brobecker To: gdb-patches@sources.redhat.com Subject: [RFC] Replace deprecated_target_new_objfile_hook by observer? Message-ID: <20061017233217.GS1903@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.4i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-10/txt/msg00206.txt.bz2 Hello, While working on the problem described in http://www.sourceware.org/ml/gdb/2006-09/msg00065.html one of the things I noticed was that we're using a hook where each client that wants to be notified inserts himself. The way it is done is through cooperation, like so: 1. Declare a static variable: static void (*target_new_objfile_chain)(struct objfile *); 2. During the module initialization, store the current value of that hook into our static variable, and replace its value with our own callback. /* Notice when object files get loaded and unloaded. */ target_new_objfile_chain = deprecated_target_new_objfile_hook; deprecated_target_new_objfile_hook = new_objfile; 3. At the end of our callback code, check our static variable and call the previous client: /* deprecated_target_new_objfile_hook callback. [snip] */ static void new_objfile (struct objfile *objfile) { [snip] if (target_new_objfile_chain) target_new_objfile_chain (objfile); } I propose to replace this with an observer. Would that be OK? Assuming that it is, there are several platforms that use that mechanism. It's going to be hard to test all of them. But the changes themselves should be pretty mechanical. So what I can propose is to make all the necessary changes to replace that hook model with an approach using observers and test on x86-linux. And then rely on the mechanical aspect of the change together with the review of another pair of eyes. Would that be OK? The alternative is to have the two approaches coexist for a while. I just don't think this is necessary, because I don't think the change is that risky. -- Joel