Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Eli Zaretskii" <eliz@gnu.org>
To: Jeff Johnston <jjohnstn@redhat.com>
Cc: drow@false.org, gdb-patches@sources.redhat.com
Subject: Re: [RFA]: Modified Watchthreads Patch
Date: Sat, 11 Dec 2004 14:34:00 -0000	[thread overview]
Message-ID: <01c4df75$Blat.v2.2.2$1a340140@zahav.net.il> (raw)
In-Reply-To: <41BA36C5.2030304@redhat.com> (message from Jeff Johnston on Fri, 10 Dec 2004 18:52:37 -0500)

> Date: Fri, 10 Dec 2004 18:52:37 -0500
> From: Jeff Johnston <jjohnstn@redhat.com>
> Cc: Daniel Jacobowitz <drow@false.org>, gdb-patches@sources.redhat.com
> 
> 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.
> 
> 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.

While I'm happy it worked for you, please be sure to test somewhat
more complex uses of watchpoints, viz.:

 . Setting several watchpoints on the same data (perhaps with
   different conditions), in the same thread and in several different
   threads.

 . use rwatch and awatch, not only watch, commands to put
   watchpoints.  As you might know, GDB handles data-write watchpoints
   with a different branch of code than what it uses for data-read and
   data-access watchpoints; we need to test both branches to be really
   sure the code works for threaded programs.

For single-threaded programs, the watchpoint support in i386-nat.c
works correctly in the above two classes of complex usage.  In
particular, it allows you to set an unlimited amount of watchpoints of
the same type on the same data, even though there are only 4 debug
registers we can use on x86.  We need to be sure that code doesn't
break for multi-threaded programs.

> As I observed before, the actual watchpoint only needs to be set on
> one thread and it will trigger in other threads.

One issue we should discuss is do we really want this behavior?  Do we
really want GDB to stop the inferior when another thread hits the
watchpoint that we set in a specific thread, or do we want a
watchpoint to break only in the thread in which it was set?  There are
valid arguments for both alternatives, and we never came to any
resolution of this issue, since back when it was discussed, the state
of support in GDB for multi-threaded programs was in flux.


  parent reply	other threads:[~2004-12-11 11:32 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
2004-12-11 14:34           ` Eli Zaretskii [this message]
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='01c4df75$Blat.v2.2.2$1a340140@zahav.net.il' \
    --to=eliz@gnu.org \
    --cc=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