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: Andrew Cagney <cagney at gnu dot org>
- To: Daniel Jacobowitz <drow at false dot org>
- Cc: Jeff Johnston <jjohnstn at redhat dot com>, Eli Zaretskii <eliz at gnu dot org>, gdb-patches at sources dot redhat dot com
- Date: Fri, 05 Nov 2004 11:52:25 -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> <20041105044917.GA13554@nevyn.them.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