Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Jeff Johnston <jjohnstn@redhat.com>
To: Daniel Jacobowitz <drow@false.org>
Cc: gdb-patches@sources.redhat.com
Subject: Re: [RFA]: Modified Watchthreads Patch
Date: Sat, 11 Dec 2004 01:28:00 -0000	[thread overview]
Message-ID: <41BA3FAE.1050409@redhat.com> (raw)
In-Reply-To: <20041210235703.GA25332@nevyn.them.org>

Daniel Jacobowitz wrote:
> On Fri, Dec 10, 2004 at 06:52:37PM -0500, Jeff Johnston wrote:
> 
>>Interesting results.  Applying my previous patch and just changing the 
>>FIXME code in dr_get_register and dr_set_register to use the standard:
>>
>>tid = TIDGET (inferior_ptid);
>>if (tid == 0)
>>  tid = PIDGET (inferior_ptid);
>>
>>allows watchthreads.exp to work for both x86 and x86_64.  For x86, I used 
>>an fc3 system with a 2.6.9-1.667smp kernel.  I had to use an RHEL3 2.4 
>>kernel for x86-64.
> 
> 
> As Eli says, there are some design issues with the rest of the x86
> watchpoint code that make me nervous about doing this.
> 
> 
>>The test sets two watchpoints that will be triggered once in the main 
>>thread and thereafter in two distinct threads.  The test verifies that each 
>>value is incremented as it should in the correct thread.  It makes sure 
>>there are no missing jumps.  I have witnessed multiple watchpoint events 
>>and thread creation events requiring processing at the same time (i.e. 
>>deferred events required) and it handles these correctly.
>>
>>I tried an experiment and broke in the thread function in one of the 
>>threads.  I then watched a variable that can only be triggered in a 
>>separate thread.  That also worked which was cool.
>>
>>As I observed before, the actual watchpoint only needs to be set on one 
>>thread and it will trigger in other threads.  I can send you the additional 
>>patch if you want to experiment with it.  I am still waiting for a machine 
>>with the latest RH kernel on it.  I'll let you know if that works the same.
> 
> 
> I'm glad to hear that it works for you.  However, since the kernel
> sources that I have here patently say that it shouldn't, we need to
> understand why.  Do the RHEL kernels have local changes to watchpoint
> support?  arch/i386/kernel/ptrace.c and arch/i386/kernel/process.c
> should have all the relevant bits.
>

There's no comments in the kernel patches (try not to laugh) and I don't know by 
looking at the patches whether any of them are affecting the watchpoint support. 
  I will ask one of the kernel folks here if they know of any local patch that 
might do this.  There are no changes to ptrace.c in the patches I have for fc3.

-- Jeff J.






  reply	other threads:[~2004-12-11  0:31 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
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 [this message]
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=41BA3FAE.1050409@redhat.com \
    --to=jjohnstn@redhat.com \
    --cc=drow@false.org \
    --cc=gdb-patches@sources.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