From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20272 invoked by alias); 14 Jan 2002 08:15:43 -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 20213 invoked from network); 14 Jan 2002 08:15:38 -0000 Received: from unknown (HELO is.elta.co.il) (199.203.121.2) by sources.redhat.com with SMTP; 14 Jan 2002 08:15:38 -0000 Received: from is (is [199.203.121.2]) by is.elta.co.il (8.9.3/8.8.8) with SMTP id KAA14273; Mon, 14 Jan 2002 10:14:49 +0200 (IST) Date: Mon, 14 Jan 2002 00:15:00 -0000 From: Eli Zaretskii X-Sender: eliz@is To: Christopher Faylor cc: gdb-patches@sources.redhat.com Subject: Re: [RFA 2] Debug register support in win32-nat.c (need opinions) In-Reply-To: <20020114015821.GA1584@redhat.com> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-01/txt/msg00383.txt.bz2 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. 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. 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.