Re: [RFA]: Modified Watchthreads Patch

Daniel Jacobowitz
2005-02-10T19:58:55Z

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