Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Daniel Jacobowitz <drow@false.org>
To: Jeff Johnston <jjohnstn@redhat.com>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA]: Modified Watchthreads Patch
Date: Fri, 10 Dec 2004 20:03:00 -0000	[thread overview]
Message-ID: <20041210191015.GA18430@nevyn.them.org> (raw)
In-Reply-To: <41B8E16D.6070505@redhat.com>

On Thu, Dec 09, 2004 at 06:36:13PM -0500, Jeff Johnston wrote:
> The following is a modified version of my thread watchpoint patch from 
> October/November.  It removes the code I had used to switch between lwp 
> ptids and thread ptids now that Daniel's lwp patch is in place.  It uses 
> the former version of my observer that is linux-specific and is activated 
> in attach_thread in linux-thread-db.c.  Eli, I renamed the observer as 
> asked to indicate this.
> 
> I also addressed Ulrich's comments regarding simplifying the S390 code and 
> using the s390_fix_watch_points call to actually put the watchpoints on the 
> new thread.
> 
> Ulrich/Daniel can you take a look to verify everything is in place.  
> Daniel, I realize that this touches files that are currently in patch state 
> for you.  I have no problem waiting for your latest patch to apply and 
> retrofitting my changes at check-in if necessary.
> 
> As I mentioned before, more is required to get ia64 threaded watchpoints to 
> work.  For S390, this change allows it to set and recognize threaded 
> watchpoints.

Two formatting comments: please replace "linux" in comments with
"GNU/Linux", and please check copyright years on the modified files.

On the technical side, two questions:

1) I can see that it will be a bit of work to rearrange i386-linux to
use this, but it should be doable.  Do you know offhand of any
i386-specific problems other than inserting watchpoints for all
threads?

2) What should to_stopped_by_watchpoint do in the presence of multiple
threads?  It looks like it relies on inferior_ptid being the thread
which stopped at a watchpoint; I'm worried that that may not be
consistently true in a heavily threaded application.  Maybe it should
iterate over all threads.

The to_stopped_data_address has its own problems with threads; but the
case of handling hitting two watchpoints at once, I think, we can leave
for another day.

This is looking very good so far!

-- 
Daniel Jacobowitz


  parent reply	other threads:[~2004-12-10 19:10 UTC|newest]

Thread overview: 56+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-12-10  4:24 Jeff Johnston
2004-12-10 13:31 ` Eli Zaretskii
2004-12-10 14:21   ` Daniel Jacobowitz
2004-12-10 18:01     ` Jeff Johnston
2004-12-24 11:05       ` Michael Snyder
2005-01-07  0:23         ` jjohnstn
2004-12-10 23:01     ` Eli Zaretskii
2004-12-10 23:31       ` Daniel Jacobowitz
2004-12-10 19:10   ` Jeff Johnston
2004-12-10 22:51     ` Eli Zaretskii
2004-12-23 22:32   ` Michael Snyder
2004-12-24 14:46     ` Eli Zaretskii
2004-12-10 20:03 ` Daniel Jacobowitz [this message]
2004-12-10 20:30   ` Jeff Johnston
2004-12-10 20:47     ` Daniel Jacobowitz
2004-12-10 22:18       ` Jeff Johnston
2004-12-10 23:57         ` Jeff Johnston
2004-12-11  0:31           ` Daniel Jacobowitz
2004-12-11  1:28             ` Jeff Johnston
2004-12-11 14:34           ` Eli Zaretskii
2004-12-11 16:56             ` Daniel Jacobowitz
2004-12-11 18:01               ` Eli Zaretskii
2004-12-11 18:06                 ` Daniel Jacobowitz
2004-12-11 19:08                   ` Eli Zaretskii
2004-12-11 19:30                     ` Daniel Jacobowitz
2004-12-12  5:22                       ` Eli Zaretskii
2004-12-11 21:54                   ` Mark Kettenis
2004-12-11 14:53           ` Mark Kettenis
2004-12-11 16:52             ` Eli Zaretskii
2004-12-11  2:04       ` Daniel Jacobowitz
2004-12-11 16:11         ` Mark Kettenis
2004-12-10 23:06   ` Eli Zaretskii
2004-12-10 23:10     ` Daniel Jacobowitz
2004-12-10 23:37       ` Eli Zaretskii
2004-12-10 23:52         ` Daniel Jacobowitz
2004-12-11 11:32           ` Eli Zaretskii
2004-12-11 14:49             ` Mark Kettenis
2004-12-11 16:48               ` Daniel Jacobowitz
2004-12-11 17:33                 ` Eli Zaretskii
2004-12-11 17:53                   ` Daniel Jacobowitz
2004-12-11 18:07                     ` Eli Zaretskii
2004-12-11 18:50                       ` Daniel Jacobowitz
2004-12-11 19:06                 ` Mark Kettenis
2004-12-11 19:07                   ` Daniel Jacobowitz
2004-12-11 16:49               ` Eli Zaretskii
2004-12-11 16:37             ` Daniel Jacobowitz
2004-12-11 17:30               ` Eli Zaretskii
2004-12-11 17:38                 ` Daniel Jacobowitz
2004-12-11 18:02                   ` Eli Zaretskii
2004-12-11 18:10                     ` Daniel Jacobowitz
2005-01-13 19:22                   ` Jeff Johnston
2005-02-11  1:57                     ` Daniel Jacobowitz
2005-02-11 18:18                       ` Eli Zaretskii
2005-02-11 18:31                         ` Daniel Jacobowitz
2005-02-12 21:50                           ` Eli Zaretskii
2004-12-11 19:35 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=20041210191015.GA18430@nevyn.them.org \
    --to=drow@false.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