From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 644 invoked by alias); 11 Dec 2004 11:32:18 -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 569 invoked from network); 11 Dec 2004 11:32:07 -0000 Received: from unknown (HELO balder.inter.net.il) (192.114.186.15) by sourceware.org with SMTP; 11 Dec 2004 11:32:07 -0000 Received: from zaretski (IGLD-83-130-247-149.inter.net.il [83.130.247.149]) by balder.inter.net.il (Mirapoint Messaging Server MOS 3.3.7-GR) with ESMTP id DXB68133 (AUTH halo1); Sat, 11 Dec 2004 13:31:21 +0200 (IST) Date: Sat, 11 Dec 2004 14:34:00 -0000 From: "Eli Zaretskii" To: Jeff Johnston Message-ID: <01c4df75$Blat.v2.2.2$1a340140@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: drow@false.org, gdb-patches@sources.redhat.com In-reply-to: <41BA36C5.2030304@redhat.com> (message from Jeff Johnston on Fri, 10 Dec 2004 18:52:37 -0500) Subject: Re: [RFA]: Modified Watchthreads Patch Reply-to: Eli Zaretskii References: <41B8E16D.6070505@redhat.com> <20041210191015.GA18430@nevyn.them.org> <41BA00E1.20900@redhat.com> <20041210203729.GA7830@nevyn.them.org> <41BA168E.7030507@redhat.com> <41BA36C5.2030304@redhat.com> X-SW-Source: 2004-12/txt/msg00294.txt.bz2 > Date: Fri, 10 Dec 2004 18:52:37 -0500 > From: Jeff Johnston > Cc: Daniel Jacobowitz , 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.