This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [patch 0/1] Threaded Watchpoints
- From: "Ulrich Weigand" <uweigand at de dot ibm dot com>
- To: drow at false dot org (Daniel Jacobowitz)
- Cc: gdb-patches at sourceware dot org
- Date: Mon, 10 Sep 2007 21:03:26 +0200 (CEST)
- Subject: Re: [patch 0/1] Threaded Watchpoints
Daniel Jacobowitz wrote:
> On Mon, Sep 10, 2007 at 08:44:22PM +0200, Ulrich Weigand wrote:
> > I guess your new way makes more sense. This means we can remove
> > HAVE_CONTINUABLE_WATCHPOINTS completely, though. (As a related
> > point, I think it would be good to fix the oddity that nonsteppable
> > watchpoints are reported as a gdbarch property while steppable
> > watchpoints are reported as a target property ...)
>
> I totally agree. I just don't know which one makes more sense.
> Probably gdbarch but I'm sure I'll break something if I try to
> change it.
I'd tend to agree with Andrew's comment in mips-tdep.c:
/* FIXME: cagney/2003-08-29: The macros HAVE_STEPPABLE_WATCHPOINT,
HAVE_NONSTEPPABLE_WATCHPOINT, and HAVE_CONTINUABLE_WATCHPOINT
need to all be folded into the target vector. Since they are
being used as guards for STOPPED_BY_WATCHPOINT, why not have
STOPPED_BY_WATCHPOINT return the type of watchpoint that the code
is sitting on? */
Since all other watchpoint-related callbacks are in the target
vector, having nonsteppable_watchpoint as a gdbarch property
does look somewhat odd.
The only problem with moving HAVE_NONSTEPPABLE_WATCHPOINT into the
target vector might be the remote targets. Is this information
available via the remote protocol somehow? If not, I guess it has
to stay in gdbarch ...
> > Hmm, I see. This assumes that after every new-thread event, the new
> > thread is selected as inferior_ptid, though.
>
> I don't think it assumes that. s390_resume should be called once for
> each thread, and not depend on inferior_ptid at all; only
> linux_nat_resume has to check for ptid == -1, schedlocking, et cetera.
Doh! You're right, of course. That should work fine then.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com