From: Daniel Jacobowitz <drow@false.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: jjohnstn@redhat.com, gdb-patches@sources.redhat.com
Subject: Re: [RFA]: Modified Watchthreads Patch
Date: Fri, 10 Dec 2004 23:10:00 -0000 [thread overview]
Message-ID: <20041210230603.GA23419@nevyn.them.org> (raw)
In-Reply-To: <01c4df0c$Blat.v2.2.2$244dda20@zahav.net.il>
On Sat, Dec 11, 2004 at 01:00:08AM +0200, Eli Zaretskii wrote:
> > Date: Fri, 10 Dec 2004 14:10:15 -0500
> > From: Daniel Jacobowitz <drow@false.org>
> > Cc: gdb-patches@sources.redhat.com
> >
> > 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?
>
> The design of the x86 watchpoint support explicitly assumes that
> watchpoints are not thread-local. If we want to lift that limitation,
> I think the x86-specific code needs to be redesigned. Someone who
> knows way more than I do about x86 threads and how the debug registers
> are handled by the relevant kernels in the presence of threads, should
> present a clean replacement design that deals with thread-local
> watchpoints. Small modifications like inserting watchpoints for all
> threads and other similar patchwork will simply not cut it, IMHO.
Does the i386 native watchpoint support work on any existing target
with multiple threads? I think this is a more accurate description of
the assumptions, even though it's from i386-linux-nat.c:
/* FIXME: kettenis/2001-01-29: It's not clear what we should do with
multi-threaded processes here. For now, pretend there is just
one thread. */
> Observe:
>
> > 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.
>
> These two are just the tip of the iceberg, but already you discovered
> that the two cornerstones of the GDB watchpoint support do not work
> reliably in multithreaded programs. We should redesign the x86
> watchpoint support instead of taking the evolutionary approach, which
> will leave us with messy, unmaintainable, and buggy code.
That is not a problem with the i386 native support for watchpoints; it
is a problem with the core GDB interfaces for watchpoints, a much
bigger problem. If you don't think we can support multi-threaded
watchpoints in GDB without doing this redesign first, do you object to
Jeff's current patch?
To get a useful level of support from the i386 watchpoint code, in
fact, looks pretty easy. Most of it would be local to the existing
low-level support routines which are implemented in an i386-linux
specific file. I can't say any more than that, since Jeff hasn't
posted his patch yet.
--
Daniel Jacobowitz
next prev parent reply other threads:[~2004-12-10 23:06 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
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 [this message]
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=20041210230603.GA23419@nevyn.them.org \
--to=drow@false.org \
--cc=eliz@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