Re: [RFA]: Watchpoints per thread patch

[Daniel Jacobowitz <drow at false dot org>]

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.

My plan is to first rename thread-db.c to mark it as clearly GNU/Linux
specific, as I was asked to do, and then change the format of ptid_t
used by thread-db to make finding the LWP trivial.  It should not take
long.  I will try to post the first part tomorrow.

> +      /* For every active watchpoint, we need to insert the watchpoint on 
> +         the new thread.  */
> +      if ((b->loc_type == bp_loc_hardware_watchpoint
> +	   || b->owner->type == bp_watchpoint))

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.

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.

-- 
Daniel Jacobowitz