Re: [RFA]: Modified Watchthreads Patch

[Jeff Johnston <jjohnstn@redhat.com>]

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?

-- Jeff J.