Re: [RFA]: Modified Watchthreads Patch

[Daniel Jacobowitz <drow@false.org>]

On Sat, Dec 11, 2004 at 01:19:03PM +0200, Eli Zaretskii wrote:
> > 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.

That's a fine kind of objection :-)

> 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.
> 
> 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?

As Mark said, the idea is that GDB is modular.  If we knew that every
time the GNU/Linux native support code was used, the architecture
native support code would need to munge watchpoints in this way, and
there were few other platforms for which it was true, then using an
observer would be silly.  But we aren't supposed to "know" what
architecture is in use when we compile linux-nat.c, and this action is
a property of the architecture.

Are there really any current uses of observers which meet your
definition above?

That said, it looks like all Linux targets (with the exception of the
current x86 mystery) have this behavior.  That gives me at least two
more ideas on how to implement it.

1)  Wait for my target vector inheritance patch to go in.  Have the
target override either to_wait or to_resume - probably to_resume.  In
the overridden version, iterate over all LWPs and make sure
watchpoints are correctly inserted for them all.  Disadvantage: we
shouldn't need to iterate over the entire LWP list for this.  But there
are enough places in GDB that don't scale easily to huge LWP lists that
I can't imagine this one being a problem in the next ten years.

2) Provide a GNU/Linux specific hook, not using the observer mechanism,
in the same way we've been connecting architectures to other individual
modules of GDB.  Implement linux_set_new_thread_watchpoints_callback,
which would be functionally similar to this observer, but have a better
defined purpose and use.

Are either of these better?

> 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?

Yes, this is a very real problem.

-- 
Daniel Jacobowitz