From: "Ulrich Weigand" <uweigand@de.ibm.com>
To: drow@false.org (Daniel Jacobowitz)
Cc: luisgpm@linux.vnet.ibm.com (Luis Machado), gdb-patches@sourceware.org
Subject: Re: [patch 0/1] Threaded Watchpoints
Date: Mon, 10 Sep 2007 18:23:00 -0000 [thread overview]
Message-ID: <200709101822.l8AIMuZG011855@d12av02.megacenter.de.ibm.com> (raw)
In-Reply-To: <20070910002103.GA25048@caradoc.them.org> from "Daniel Jacobowitz" at Sep 09, 2007 08:21:03 PM
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
next prev parent reply other threads:[~2007-09-10 18:23 UTC|newest]
Thread overview: 17+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-08-13 13:51 Luis Machado
2007-08-20 17:33 ` Luis Machado
2007-08-20 17:40 ` Luis Machado
2007-09-05 2:04 ` Daniel Jacobowitz
2007-09-05 12:31 ` Luis Machado
2007-09-10 0:21 ` Daniel Jacobowitz
2007-09-10 15:34 ` Luis Machado
2007-09-10 15:44 ` Daniel Jacobowitz
2007-09-10 17:56 ` Luis Machado
2007-09-10 18:30 ` Daniel Jacobowitz
2007-09-10 18:23 ` Ulrich Weigand [this message]
2007-09-10 18:29 ` Daniel Jacobowitz
2007-09-10 18:44 ` Ulrich Weigand
2007-09-10 18:54 ` Daniel Jacobowitz
2007-09-10 19:03 ` Ulrich Weigand
2007-09-10 19:12 ` Daniel Jacobowitz
2007-09-10 19:31 ` Mark Kettenis
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200709101822.l8AIMuZG011855@d12av02.megacenter.de.ibm.com \
--to=uweigand@de.ibm.com \
--cc=drow@false.org \
--cc=gdb-patches@sourceware.org \
--cc=luisgpm@linux.vnet.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox