This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [RFA]: Watchpoints per thread patch
- From: Daniel Jacobowitz <drow at false dot org>
- To: Jeff Johnston <jjohnstn at redhat dot com>
- Cc: Eli Zaretskii <eliz at gnu dot org>, cagney at gnu dot org,gdb-patches at sources dot redhat dot com
- Date: Thu, 4 Nov 2004 23:49:18 -0500
- Subject: Re: [RFA]: Watchpoints per thread patch
- References: <4175A9C9.8040300@redhat.com> <41769FF3.7010801@gnu.org> <20041020173035.GA26622@nevyn.them.org> <418022DE.204@redhat.com> <01c4bca9$Blat.v2.2.2$adcffb00@zahav.net.il> <418A741C.4080306@redhat.com>
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