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.