From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25598 invoked by alias); 14 Jan 2002 08:33:47 -0000 Mailing-List: contact gdb-patches-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sources.redhat.com Received: (qmail 25559 invoked from network); 14 Jan 2002 08:33:44 -0000 Received: from unknown (HELO cerbere.u-strasbg.fr) (130.79.112.7) by sources.redhat.com with SMTP; 14 Jan 2002 08:33:44 -0000 Received: from laocoon (laocoon.u-strasbg.fr [130.79.112.72]) by cerbere.u-strasbg.fr (8.9.3/8.8.7) with ESMTP id JAA08301 for ; Mon, 14 Jan 2002 09:33:42 +0100 Message-Id: <4.2.0.58.20020114092549.00acd1d8@ics.u-strasbg.fr> X-Sender: muller@ics.u-strasbg.fr X-Mailer: QUALCOMM Windows Eudora Pro Version 4.2.0.58 Date: Mon, 14 Jan 2002 00:33:00 -0000 To: gdb-patches@sources.redhat.com From: Pierre Muller Subject: Re: [RFA 2] Debug register support in win32-nat.c (need opinions) In-Reply-To: References: <20020114015821.GA1584@redhat.com> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-SW-Source: 2002-01/txt/msg00384.txt.bz2 At 09:14 14/01/2002 , Eli Zaretskii a écrit: >On Sun, 13 Jan 2002, Christopher Faylor wrote: > > > >I agree that the linux implementation does not set the debug registers > > >for all threads but this means that if a watched expression is modified > > >by another thread than the current thread at the time of setting the > > >watchpoint will not be caught and that is much worse... > > > > You described this in your original email. I should have responded to > > it. > > > > I don't think it makes sense to make gratuitous changes to the way gdb > > works. If you're implementing an improvement for gdb for Windows then > > I think it should probably work the same way for Windows as it does > > for linux. > > > > I guess I need a ruling from more experienced maintainers about this. > > > > How should gdb behave in this scenario? > >I'm not an expert, so this is FWIW: > >The basic assumption behind the generic x86 watchpoint code in >i386-nat.c is that the watchpoints are not thread-specific. That's >why i386-nat.c stores the info in a single array that doesn't have >thread information, and that's why the I386_DR_LOW_* macros don't >accept a thread id as an argument. Anyway, it is not even possible yet to specify a thread index for a watchpoint, the command pareser only accepts a thread argument for normal breakpoints. >IIRC, this issue was discussed back when I published the first draft >of the watchpoint API, and the general consensus was that I shouldn't >bother about thread-specific watchpoints. You may wish to reread that >discussion (I can dig out a pointer to it if you cannot find it.) > >I also agree with Pierre that global watchpoints are much better than >thread-local ones. For starters, you can always write a condition for >a global watchpoint that lets the debuggee continue if the thread id >is not what you want; but pulling the reverse trick with thread-local >watchpoints is impossible. Thanks for your comments, Eli. >So if indeed GNU/Linux versions of GDB set watchpoints on a per thread >basis (I'm surprised they do), I think that's a misfeature, to say the >least. You can see this is a comment added by Mark Kettenis at line 707 of i386-linux-nat.c file: /* 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. */ Mark, wouldn't it be just enough to loop over the the thread chain and call ptrace for each pid? In any case, this comment clearly shows that the coreect behavior of a watchpoint should be that it is triggered in all threads. Christopher, does this answer your concerns? Pierre Muller Institut Charles Sadron 6,rue Boussingault F 67083 STRASBOURG CEDEX (France) mailto:muller@ics.u-strasbg.fr Phone : (33)-3-88-41-40-07 Fax : (33)-3-88-41-40-99