Re: [RFA]: Watchpoints per thread patch

Daniel Jacobowitz
2004-11-05T04:49:22Z

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