Re: [RFA]: Watchpoints per thread patch

[Daniel Jacobowitz <drow@false.org>]

On Fri, Nov 05, 2004 at 11:52:25AM -0500, Andrew Cagney wrote:
> Daniel Jacobowitz wrote:
> >I don't want to add target_get_lwp only to remove it a couple weeks
> >later!  I don't think this patch is appropriate for 6.3; for the
> >mainline, we have plenty of time, so please wait a little longer.
> 
> You're correct, it definitly isn't appropriate for 6.3.  However, it is 
> appropriate for mainline.  Lets get this patch off the table (and have 
> working watchpoints), that way we're in a position to better focus on 
> just the refactorings you talk of.  Especially since, this work gives us 
> a working test case that we can refactor against.
> 
> Sound reasonable?

Andrew, I'm confused.  Aren't you the maintainer who is historically
most likely to jump on contributors for kludging around missing
infrastructure?  I think we should solve this correctly, not with (so
far) two majorly incorrect hacks.

And we've already got working watchpoints.  This is for multi-threaded
hardware watchpoints, which have never worked right in GDB and thus
seem to me like a new feature.

> >You were going to fix this bit.
> >
> >Also, I have been thinking about your approach.  You are hooking native
> >code in via an observer; observers bypass the target stack.  It worked
> >while you were only calling this observer from the GNU/Linux native
> >support in thread-db.c.  But now it will mess up if you use a native
> >ia64 debugger connected to a remote target, in which case we should
> >never enter the ia64-nat code - there's nothing to ptrace.
> 
> Jeff,
> 
> I'd use the cludge based on what is found in remote.c:
>   if (!current_target.to_shortname ||
>       strcmp (current_target.to_shortname, "remote") != 0)
>     error ("command can only be used with remote target");
> we need to solve the problem daniel describes but that involves 
> structural change.

There are plenty of other ways to solve this.  This entire operation
should go through the target stack. My cleanups, and yours, are
bringing us to the day when target vector inheritance can be used for
GNU/Linux; then we can do this properly. The precedent of using
observers to support target-stack-specific code is a horrible one that
we should avoid.

Then targets which need this operation can supply a
target_fixup_watchpoints_for_new_thread, and the observer can live in
core code instead of each target.  Doesn't that seem like a better
solution?

-- 
Daniel Jacobowitz