From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12399 invoked by alias); 17 Oct 2006 23:35:30 -0000 Received: (qmail 12389 invoked by uid 22791); 17 Oct 2006 23:35:30 -0000 X-Spam-Check-By: sourceware.org Received: from nevyn.them.org (HELO nevyn.them.org) (66.93.172.17) by sourceware.org (qpsmtpd/0.31.1) with ESMTP; Tue, 17 Oct 2006 23:35:27 +0000 Received: from drow by nevyn.them.org with local (Exim 4.54) id 1GZySy-0004jM-NH; Tue, 17 Oct 2006 19:35:24 -0400 Date: Tue, 17 Oct 2006 23:35:00 -0000 From: Daniel Jacobowitz To: Joel Brobecker Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] Replace deprecated_target_new_objfile_hook by observer? Message-ID: <20061017233524.GA18064@nevyn.them.org> Mail-Followup-To: Joel Brobecker , gdb-patches@sources.redhat.com References: <20061017233217.GS1903@adacore.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20061017233217.GS1903@adacore.com> User-Agent: Mutt/1.5.13 (2006-08-11) X-IsSubscribed: yes 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/msg00207.txt.bz2 On Tue, Oct 17, 2006 at 07:32:17PM -0400, Joel Brobecker wrote: > I propose to replace this with an observer. Would that be OK? There Be Dragons! Note that there is a case where the remote objfile hook does _not_ call the next thing on the chain. This is somewhat deliberate, in that it's what prevents thread-db from being enabled when talking to gdbserver, and somewhat accidental, in that I'm sure it wasn't meant to work this way. But we'll need to do some rearranging in order to keep the current state of affairs working. > 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? Isn't there already an adequate observer? Well, not a single one I guess, you'd have to survey the uses and see what they really wanted. But solib_loaded goes a long way. -- Daniel Jacobowitz CodeSourcery