Re: [RFA]: Modified Watchthreads Patch

[Daniel Jacobowitz <drow@false.org>]

On Thu, Jan 13, 2005 at 02:22:45PM -0500, Jeff Johnston wrote:
> Daniel Jacobowitz wrote:
> >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.
> >
> 
> Sorry, I should have responded to this ages ago.  I prefer #2.  I assume 
> the hook resides in the target vector or have you got some other idea in 
> mind?

I believe I was waiting for further feedback from Eli on the role of
observers within GDB.  That's why I never got back to you.  Sorry.

No, it would not reside in the target vector.  I had something like
dwarf2_frame_set_signal_frame_p in mind.

-- 
Daniel Jacobowitz
CodeSourcery, LLC