Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andrew Cagney <cagney@gnu.org>
To: Jeff Johnston <jjohnstn@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA]: Watchpoints per thread patch
Date: Wed, 20 Oct 2004 17:27:00 -0000	[thread overview]
Message-ID: <41769FF3.7010801@gnu.org> (raw)
In-Reply-To: <4175A9C9.8040300@redhat.com>

Jeff Johnston wrote:
> The following patch adds needed support for the ia64 and s390 
> platforms.  For these platforms, watchpoints need to be inserted / 
> removed on each thread so as to work across all threads.  The patch adds 
> support for detecting this at configuration time and setting a new flag 
> WATCHPOINTS_PER_THREAD.  This flag is used when inserting/removing 
> watchpoints and when a new thread event occurs.
> 
> This patch in itself does not give these platforms threaded watchpoint 
> support to pass the watchthreads.exp test case, but I am breaking up my 
> bigger patch that works for x86, x86_64, and ia64.  It still fails on 
> the S390 but gets part marks because threaded watchpoints actually 
> trigger properly however the S390 cannot determine which watchpoint gets 
> triggered when multiple watchpoint events occur. On ia64, the 
> watchthreads.exp test case will fail differently than before because the 
> low-level register and watchpoint code does not properly calculate the 
> LWP for accessing registers so we end up eating through the maximum 
> number of watchpoints quicker than anticipated.  I have a subsequent 
> patch for getting the LWP reliably, but this subsequent patch may be 
> made unnecessary depending on what Daniel does with ptids and the 
> thread-db layer.  Regardless of Daniel's redesign, the watchpoints still 
> must be inserted/removed on each thread.

The controversy here appears to be with the target dependant code being 
added to breakpoint.c.

For the target's that have the problem, modify target_insert_watchpoint 
to include the code your adding.  That way, instead of:

> +  /* If watchpoints do not apply to all threads automatically, we have to insert
> +     and delete them for every thread.  Otherwise, we can insert or delete them
> +     once from any thread.  */
> +#ifdef WATCHPOINTS_PER_THREAD
> +  val = thread_switch_and_call (bpt->owner->thread, &insert_one_watchpoint, &args);
> +#else
> +  val = insert_one_watchpoint (&args);
> +#endif

the underlying target (ia64-linux-nat, ...) can locally override the 
method and handle the problem.  The code's the same, but how it is wired 
up is different

Sound reasonable to all?

Andrew


  parent reply	other threads:[~2004-10-20 17:27 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-10-19 23:57 Jeff Johnston
2004-10-20  5:04 ` Eli Zaretskii
2004-10-20 11:03 ` Mark Kettenis
2004-10-20 16:21   ` Jeff Johnston
2004-10-20 17:27 ` Andrew Cagney [this message]
2004-10-20 17:30   ` Daniel Jacobowitz
2004-10-27 22:36     ` Jeff Johnston
2004-10-27 22:41       ` Daniel Jacobowitz
2004-10-27 23:17         ` Jeff Johnston
2004-10-28 13:33           ` Daniel Jacobowitz
2004-10-28 19:47             ` Jeff Johnston
2004-10-28 19:52               ` Daniel Jacobowitz
2004-10-28 20:13                 ` Jeff Johnston
2004-10-28  4:55       ` Eli Zaretskii
2004-11-04 18:25         ` Jeff Johnston
2004-11-04 21:21           ` Eli Zaretskii
2004-11-05  4:49           ` Daniel Jacobowitz
2004-11-05 16:52             ` Andrew Cagney
2004-11-05 18:29               ` Daniel Jacobowitz
2004-11-08 21:33                 ` Andrew Cagney
2004-11-09  1:04                   ` Daniel Jacobowitz
2004-11-09  2:20                     ` Andrew Cagney
2004-11-09  2:33                       ` Daniel Jacobowitz
2004-11-09  4:53                         ` Eli Zaretskii
2004-11-09 15:11                         ` Andrew Cagney
2004-11-09 18:41                           ` Daniel Jacobowitz
2004-11-11 21:22                             ` Andrew Cagney
2004-11-09 19:06                         ` Jeff Johnston
2004-11-09 19:31                           ` Daniel Jacobowitz
2004-11-09 20:24                             ` Jim Blandy
2004-11-10  0:02                               ` Jeff Johnston
2004-11-10 14:39                                 ` Jim Blandy
2004-11-11 21:23                                 ` Andrew Cagney
2004-11-09 20:48                             ` Jeff Johnston
2004-11-09 20:50                               ` Daniel Jacobowitz
2004-11-10 19:45                               ` Eli Zaretskii
2004-11-10 22:08                                 ` Jeff Johnston
2004-11-10 19:43                             ` Eli Zaretskii
2004-10-20 19:27   ` Eli Zaretskii
2004-11-05 11:49 Ulrich Weigand

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=41769FF3.7010801@gnu.org \
    --to=cagney@gnu.org \
    --cc=gdb-patches@sources.redhat.com \
    --cc=jjohnstn@redhat.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