Re: [RFA]: Modified Watchthreads Patch

[Mark Kettenis <kettenis at gnu dot org>]

   Date: Sat, 11 Dec 2004 13:19:03 +0200
   From: "Eli Zaretskii" <eliz@gnu.org>

   > Date: Fri, 10 Dec 2004 18:37:00 -0500
   > From: Daniel Jacobowitz <drow@false.org>
   > Cc: jjohnstn@redhat.com, gdb-patches@sources.redhat.com
   > 
   > I waited to review the revised version until you had a chance to
   > comment on the continued use of observers.

   I still object to the use of observers for a purpose such as this one.
   My objections are a bit philosophical, though.

   Basically, I think that observers are a last-resort mechanism for
   anything that is part of the GDB infrastructure.  It's like hooks or
   callbacks--you don't normally expect a program internals to use
   callbacks that it provides for higher-level application code.

I somewhat disagree here.  GDB is modularized.  Depending on the
configuration, some parts may be present, other parts may not.
Observers provide a very useful mechanism for interaction between
modules without the need to know exactly which modules are present or
not.  But...

   Put another way, using a mechanism such as observers for internal code
   means we leave our internal structure not entirely defined.  We design
   the internals, so we ought to know what needs to be done where and
   when.  For example, this particular usage of an observer means that we
   don't really know in advance that watchpoint insertion needs to be
   done for each thread when it is being attached.  Do we really want to
   say that we don't know what we are doing in our own program?

...indeed.  It's a bit strange that there's a need for a
Linux-specific observer.  The Linux-specific code should know the
details isn't it?  Unfortunately the situation is a bit murky.  The
implementation of hardware (or kernel-assisted) watchpoints is very
platform-dependent.  And on top of that, because of the poor
thread-debugging interface that Linux has, we never really know what
threads/lwps actaully exist within a process.  This may call for
unorthodox ways of handling things.

Personally I think that it's better to declare watchpoints in
multi-threaded programs as unsupported.  Then add a sane interface for
debugging threads and watchpoints to the kernel, before revisiting the
issue in GDB.  I mean, it's like the Linux kernel is no longer Open
Source.

Adding hacks around hacks, like we've been doing to support threads on
Linux for quite some time now is defenitely not a good idea.

   In addition, proliferation of observers' use will sooner or later
   raise the issue of the order of the observer invocation, since we lack
   a machinery for invoking a series of observers in a controlled manner:
   we cannot control the order of their invocation and we cannot tell GDB
   to stop invoking any additional observers.  The current machinery
   assumes that each observer is orthogonal to others in its side
   effects; what if this assumption doesn't hold?

I think we should take a different viewpoint here.  The current
machinery doesn't *assume* that each observer is orthogonal, it's the
*definition* of the interface.  If an observer makes the assumption
that another observer has done its "thing", then that's a programming
error.  This error could be fixed by introducing another notification
that documents that the "thing" has been taken care of.

Mark