From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20784 invoked by alias); 11 Dec 2004 14:34:34 -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 20754 invoked from network); 11 Dec 2004 14:34:25 -0000 Received: from unknown (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 11 Dec 2004 14:34:25 -0000 Received: from elgar.sibelius.xs4all.nl (elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id iBBEY1LM026230; Sat, 11 Dec 2004 15:34:01 +0100 (CET) Received: from elgar.sibelius.xs4all.nl (localhost [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6) with ESMTP id iBBEY1c4007240; Sat, 11 Dec 2004 15:34:01 +0100 (CET) (envelope-from kettenis@elgar.sibelius.xs4all.nl) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.12.6p3/8.12.6/Submit) id iBBEXqpN007235; Sat, 11 Dec 2004 15:33:52 +0100 (CET) Date: Sat, 11 Dec 2004 14:49:00 -0000 Message-Id: <200412111433.iBBEXqpN007235@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: eliz@gnu.org CC: drow@false.org, jjohnstn@redhat.com, gdb-patches@sources.redhat.com In-reply-to: <01c4df73$Blat.v2.2.2$5e13b740@zahav.net.il> (eliz@gnu.org) Subject: Re: [RFA]: Modified Watchthreads Patch 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> X-SW-Source: 2004-12/txt/msg00295.txt.bz2 Date: Sat, 11 Dec 2004 13:19:03 +0200 From: "Eli Zaretskii" > Date: Fri, 10 Dec 2004 18:37:00 -0500 > From: Daniel Jacobowitz > Cc: jjohnstn@redhat.com, gdb-patches@sources.redhat.com > > I waited to review the revised version until you had a chance to > comment on the continued use of observers. I still object to the use of observers for a purpose such as this one. My objections are a bit philosophical, though. Basically, I think that observers are a last-resort mechanism for anything that is part of the GDB infrastructure. It's like hooks or callbacks--you don't normally expect a program internals to use callbacks that it provides for higher-level application code. I somewhat disagree here. GDB is modularized. Depending on the configuration, some parts may be present, other parts may not. Observers provide a very useful mechanism for interaction between modules without the need to know exactly which modules are present or not. But... Put another way, using a mechanism such as observers for internal code means we leave our internal structure not entirely defined. We design the internals, so we ought to know what needs to be done where and when. For example, this particular usage of an observer means that we don't really know in advance that watchpoint insertion needs to be done for each thread when it is being attached. Do we really want to say that we don't know what we are doing in our own program? ...indeed. It's a bit strange that there's a need for a Linux-specific observer. The Linux-specific code should know the details isn't it? Unfortunately the situation is a bit murky. The implementation of hardware (or kernel-assisted) watchpoints is very platform-dependent. And on top of that, because of the poor thread-debugging interface that Linux has, we never really know what threads/lwps actaully exist within a process. This may call for unorthodox ways of handling things. 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. Adding hacks around hacks, like we've been doing to support threads on Linux for quite some time now is defenitely not a good idea. 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. If an observer makes the assumption that another observer has done its "thing", then that's a programming error. This error could be fixed by introducing another notification that documents that the "thing" has been taken care of. Mark