Re: [RFA]: Watchpoints per thread patch

[Andrew Cagney <cagney@gnu.org>]

Daniel Jacobowitz wrote:
> On Thu, Nov 04, 2004 at 01:25:32PM -0500, Jeff Johnston wrote:
> 
>>Daniel, I have moved the observer notification to add_thread as suggested.  
>>To do this, I had to move a few things in attach_thread.  As well, I had to 
>>add another part of my full patch in because the ptid that add_thread knows 
>>about is in the wrong format (pid, 0, tid).  The low-level insert 
>>watchpoint code needs the lwp so I have added in my target_get_lwp change.  
>>I realize you have plans to change how the ptid is kept, but until that is 
>>fleshed out, this change is required.  I used a call-back to allow 
>>breakpoint.c which knows how to handle watchpoints to communicate with the 
>>low-level linux code that knows how to insert/remove a watchpoint.
> 
> 
> 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?

> 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.

> The observer could move back to thread-db, but as Andrew keeps
> reminding me, there are situations where we could take advantage of
> thread-db for things like core files.  This is a target stack activity;
> I think we need to find a way to do it without violating the
> abstraction of the target stack.

There are two concurrency abstractions:
	- light-weight-processes
		system level
	- threads
		user level
burried in the target stack, here the code is manipulating the former, 
thread-db manipulates the latter.  That the abstractions are not clearly 
separated is a design flaw, but not one we're going to immediatly fix here.

Andrew