Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Joel Brobecker <brobecker@adacore.com>
To: gdb-patches@sources.redhat.com
Subject: [RFC] Replace deprecated_target_new_objfile_hook by observer?
Date: Tue, 17 Oct 2006 23:32:00 -0000	[thread overview]
Message-ID: <20061017233217.GS1903@adacore.com> (raw)

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


             reply	other threads:[~2006-10-17 23:32 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2006-10-17 23:32 Joel Brobecker [this message]
2006-10-17 23:35 ` Daniel Jacobowitz
2006-10-18  0:20   ` Joel Brobecker
2006-10-18  1:38     ` Daniel Jacobowitz
     [not found]       ` <535BF17A-E776-4DE4-979B-7E6FBA505E31@apple.com>
2006-10-18 17:11         ` Daniel Jacobowitz
2006-10-18 16:29   ` Ulrich Weigand
2006-10-18 16:43     ` Daniel Jacobowitz
2006-10-19 14:30     ` Joel Brobecker
2006-10-20  0:41       ` [PATCH] " Ulrich Weigand
2006-10-20  0:46         ` Daniel Jacobowitz
2006-10-20  1:09           ` Ulrich Weigand
2007-03-28 18:34       ` Ulrich Weigand
2007-03-28 18:42         ` Joel Brobecker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20061017233217.GS1903@adacore.com \
    --to=brobecker@adacore.com \
    --cc=gdb-patches@sources.redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox