Re: [RFA]: Modified Watchthreads Patch

[Daniel Jacobowitz <drow at false dot org>]

On Sat, Dec 11, 2004 at 06:54:53PM +0200, Eli Zaretskii wrote:
> > Date: Sat, 11 Dec 2004 11:11:37 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: jjohnstn@redhat.com, gdb-patches@sources.redhat.com
> > 
> > Are there really any current uses of observers which meet your
> > definition above?
> 
> I'm unsure which definition you refer to.

Let me try to clarify then... this is what you said:

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

I think that every current use of observers is in this sense "we don't
really know in advance what needs to be done".  For instance, we've got
observer_notify_inferior_created, which is uesd for actions that we
don't know statically will be necessary at inferior creation - vsyscall
DSO loading on targets which have one, and some HP/UX specific code
that I don't recall the purpose of.

Or consider target_changed, which is attached by the frame code (always
part of GDB!) and the regcache (likewise!) and notified by valops.c
(likewise!).

I think this is a fine use of observers; one "module" of GDB wants to
be notified when an event occurs in another.

> > 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?
> 
> Either one of them is better.

Great!  Jeff, Mark, do you have opinions on either (or other
suggestions)?

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.  In one case
it would have to be documented in observers.texi and support functions
would be autogenerated; in the other case it would probably be
documented in comments, and bunch of support functions would have to be
written by hand, instead of being generated by the observers shell script.

-- 
Daniel Jacobowitz