From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22735 invoked by alias); 13 Aug 2002 20:49:43 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 22727 invoked from network); 13 Aug 2002 20:49:41 -0000 Received: from unknown (HELO zenia.red-bean.com) (66.244.67.22) by sources.redhat.com with SMTP; 13 Aug 2002 20:49:41 -0000 Received: (from jimb@localhost) by zenia.red-bean.com (8.11.6/8.11.6) id g7DKdxL06637; Tue, 13 Aug 2002 15:39:59 -0500 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: HP catchpoint code References: <20020812153334.GA30891@nevyn.them.org> From: Jim Blandy In-Reply-To: <20020812153334.GA30891@nevyn.them.org> User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2.90 Date: Tue, 13 Aug 2002 13:49:00 -0000 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-SW-Source: 2002-08/txt/msg00124.txt.bz2 Daniel Jacobowitz writes: > I'm working on GNU/Linux support for fork and exec catchpoints. The kernel > code I needed (well, wanted; it's possible without, just bloody awkward) was > straightforward, and I already have strace using it. When I started digging > into the GDB code for it I got a little quagmired, though. > > My plan is to completely ignore the existing support for this feature. An > astute code reviewer will note that it doesn't work anywhere but HP/UX; the > code to initialize it is only present for ttrace. The target-independent > portions of it are completely dependent on the ttrace model. I'd like to > rename, or at least recomment, TARGET_WAITKIND_FORKED (and VFORKED, possibly > EXECD, haven't gotten to that one yet) to indicate their HP-specificness and > add some new waitkinds for the different model I'm using. Any objections? Those were introduced by TIHPM; I gather that HP designed them with the intention of doing things right --- generic mechanisms built on an HP-specific layer --- but they never discussed the design with the rest of the GDB scene, and the supposedly generic stuff didn't end up as generic as it should have been. (To be fair, I think HP did the work in the Old Bad Days, when `the rest of the GDB scene' was a private list within Cygnus. There was a public list, but it wasn't very active --- who wants to have a design discussion in a forum where there is clearly nothing going on?) I'm uncomfortable just renaming the old stuff and moving on --- if we're going to replace it with something better, I'd like to have some plan for eventually getting rid of the old stuff altogether. For example, would it make sense to set a deadline by which the old stuff would go away? It looks like the PA, and thus ttrace, is scheduled to be obsoleted; we could obsolete the old catchpoint stuff at that point, too, without repercussions beyond what the obsoleting will cause by itself. Could you talk more about the new catchpoint implementation you have in mind? (Maybe you did and I missed it --- sorry if so.)