Re: [RFA]: Modified Watchthreads Patch

[Daniel Jacobowitz <drow at false dot org>]

On Fri, Feb 11, 2005 at 07:03:20PM +0200, Eli Zaretskii wrote:
> Perhaps I misunderstood, but the above 2 alternatives don't use
> observers.  And since these are Linux-specific issues, I left it to
> Daniel and you to select the best alternative.
> 
> In other words, I don't think you need any input from me to decide how
> to solve this.  Am I missing something?

No, you aren't.  For this problem, we're set.  However, I'd like to
discuss the design principle for a bit, so that we know how to approach
this problem in the future.  I found the message I was thinking of.  I
wrote:

  <quote>

  > > Observe, we're back to the core question of the role of observers here.
  > > I prefer #2 to #1.  But #2 is _functionally_ equivalent to providing an
  > > observer named linux_enable_watchpoints_for_new_threads.
  >
  > It is functionally equivalent, but ideologically different: it's a
  > detail of GDB internals as opposed to a general-purpose extension
  > mechanism.

  I do not consider GDB's observer mechanism to be a general-purpose
  extension mechanism.  Some day, if there is a revival of libgdb, then
  maybe it will be usable as one - and at that point, perhaps we'll need
  a second copy with different events.  I think the current observers are
  a mechanism for nominally independent internal modules of GDB to
  communicate.

  Are "breakpoint" and "shared library" any more independent than
  "common Linux support" and "some particular Linux backend"?  Maybe so,
  but the line seems pretty shaky to me.  Certainly the breakpoint module
  has a lot of code to handle shared libraries, and the shared library
  code makes use of breakpoints.

  </quote>

My current feeling is that either:
  (A) we should use the same mechanism to create two sets of hooks,
      one to be considered a general extension mechanism and the other
      an internal modularity aid;
or
  (B) we should define the observers as the latter rather than the
      former, and declare the former niche unfilled.

Otherwise there's just a lot of wasted code duplication.

What do you think?  Am I way off on the role of observers?  Since we
don't "support" plugging arbitrary code into them, I have trouble
considering them an extension mechanism.

-- 
Daniel Jacobowitz
CodeSourcery, LLC