From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 12478 invoked by alias); 11 Dec 2004 16:48:25 -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 12453 invoked from network); 11 Dec 2004 16:48:20 -0000 Received: from unknown (HELO legolas.inter.net.il) (192.114.186.24) by sourceware.org with SMTP; 11 Dec 2004 16:48:20 -0000 Received: from zaretski (pns03-203-109.inter.net.il [80.230.203.109]) by legolas.inter.net.il (MOS 3.5.5-GR) with ESMTP id DHU73012 (AUTH halo1); Sat, 11 Dec 2004 18:46:53 +0200 (IST) Date: Sat, 11 Dec 2004 16:49:00 -0000 From: "Eli Zaretskii" To: Mark Kettenis Message-ID: <01c4dfa1$Blat.v2.2.2$2ee980c0@zahav.net.il> Content-Transfer-Encoding: 7BIT Content-Type: text/plain; charset=ISO-8859-1 CC: drow@false.org, jjohnstn@redhat.com, gdb-patches@sources.redhat.com In-reply-to: <200412111433.iBBEXqpN007235@elgar.sibelius.xs4all.nl> (message from Mark Kettenis on Sat, 11 Dec 2004 15:33:52 +0100 (CET)) Subject: Re: [RFA]: Modified Watchthreads Patch Reply-to: Eli Zaretskii References: <41B8E16D.6070505@redhat.com> <20041210191015.GA18430@nevyn.them.org> <01c4df0c$Blat.v2.2.2$244dda20@zahav.net.il> <20041210230603.GA23419@nevyn.them.org> <01c4df10$Blat.v2.2.2$6f63d1a0@zahav.net.il> <20041210233700.GA24439@nevyn.them.org> <01c4df73$Blat.v2.2.2$5e13b740@zahav.net.il> <200412111433.iBBEXqpN007235@elgar.sibelius.xs4all.nl> X-SW-Source: 2004-12/txt/msg00300.txt.bz2 > Date: Sat, 11 Dec 2004 15:33:52 +0100 (CET) > From: Mark Kettenis > CC: drow@false.org, jjohnstn@redhat.com, gdb-patches@sources.redhat.com > > Personally I think that it's better to declare watchpoints in > multi-threaded programs as unsupported. Then add a sane interface for > debugging threads and watchpoints to the kernel, before revisiting the > issue in GDB. I mean, it's like the Linux kernel is no longer Open > Source. I wasn't aware the situation was that bad, but if it is, I cannot agree more. > In addition, proliferation of observers' use will sooner or later > raise the issue of the order of the observer invocation, since we lack > a machinery for invoking a series of observers in a controlled manner: > we cannot control the order of their invocation and we cannot tell GDB > to stop invoking any additional observers. The current machinery > assumes that each observer is orthogonal to others in its side > effects; what if this assumption doesn't hold? > > I think we should take a different viewpoint here. The current > machinery doesn't *assume* that each observer is orthogonal, it's the > *definition* of the interface. First, this definition should be spelled out in the documentation. But even if it is, it's dangerous to rely on programmers working independently to never step on each other's feet.