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: luisgpm at linux dot vnet dot ibm dot com (Luis Machado), gdb-patches at sourceware dot org
- Date: Mon, 10 Sep 2007 20:22:56 +0200 (CEST)
- Subject: Re: [patch 0/1] Threaded Watchpoints
Dan Jacobowitz wrote:
> Most of this is liberally borrowed from Jeff's (and your's and Jan's)
> work. There are some bits I'm not happy with yet, but I hope I'll
> have time to finish it up this week or next weekend, and then I will
> submit each logical change separately. Some of them deserve more
> explanation (and comments and gdbint documentation).
Thanks for working on this! I like the simplification of the infrun
logic handling steppable/nonsteppable watchpoints.
Was the change to remove use of HAVE_CONTINUABLE_WATCHPOINTS deliberate?
It used to be that you had to set one of the three flags in order to
activate the watchpoint logic at all, but your new code will always
call STOPPED_BY_WATCHPOINT.
Another question:
+static void
+s390_resume (ptid_t ptid, int step, enum target_signal signal)
+{
+ if (linux_nat_lwp_is_new (ptid))
+ s390_fix_watch_points (ptid);
+ super_resume (ptid, step, signal);
+}
This assumes that the new thread's ptid will always be passed to the
resume. Is this necessarily the case? I would expect ptid to be -1
in most cases ...
> I've regression tested i386, amd64, and ia64. I tested S/390 by hand
> and it works, but the extra logic in watchthreads.exp for that
> platform hasn't been tested (no DejaGNU or expect on my test system).
I did a full test on s390-ibm-linux and s390x-ibm-linux, and it works
fine. There are no longer any FAILs reported for watchthreads.exp.
I did have to define PTRACE_GETSIGINFO in linux-nat.c to get it to
compile, however.
Bye,
Ulrich
--
Dr. Ulrich Weigand
GNU Toolchain for Linux on System z and Cell BE
Ulrich.Weigand@de.ibm.com