This is the mail archive of the gdb-patches@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [RFA]: Modified Watchthreads Patch


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]