From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 17440 invoked by alias); 26 Jul 2005 21:02:35 -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 17350 invoked by uid 22791); 26 Jul 2005 21:02:22 -0000 Received: from sibelius.xs4all.nl (HELO sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.30-dev) with ESMTP; Tue, 26 Jul 2005 21:02:22 +0000 Received: from elgar.sibelius.xs4all.nl (root@elgar.sibelius.xs4all.nl [192.168.0.2]) by sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id j6QL259A032588; Tue, 26 Jul 2005 23:02:05 +0200 (CEST) Received: from elgar.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by elgar.sibelius.xs4all.nl (8.13.4/8.13.3) with ESMTP id j6QL24WN003870; Tue, 26 Jul 2005 23:02:04 +0200 (CEST) Received: (from kettenis@localhost) by elgar.sibelius.xs4all.nl (8.13.4/8.13.4/Submit) id j6QL240v002680; Tue, 26 Jul 2005 23:02:04 +0200 (CEST) Date: Tue, 26 Jul 2005 21:02:00 -0000 Message-Id: <200507262102.j6QL240v002680@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: drow@false.org CC: gdb-patches@sourceware.org In-reply-to: <20050725221944.GA19564@nevyn.them.org> (message from Daniel Jacobowitz on Mon, 25 Jul 2005 18:19:44 -0400) Subject: Re: [commit] Follow forks on HP-UX 10.20 References: <200507252212.j6PMCS3j015796@elgar.sibelius.xs4all.nl> <20050725221944.GA19564@nevyn.them.org> X-SW-Source: 2005-07/txt/msg00201.txt.bz2 Date: Mon, 25 Jul 2005 18:19:44 -0400 From: Daniel Jacobowitz On Tue, Jul 26, 2005 at 12:12:28AM +0200, Mark Kettenis wrote: > Finally, the goal of this excercise. The code is also going to be > used on OpenBSD when I get the necessary kernel stuff committed. It > doesn't do follow-vfork yet. HP-UX 10.20 doesn't really allow you to > do anything with a vforked child until it execs. So follow-vfork > isn't useful until follow-exec is properly implemented. > > Committed, I'm not really sure this is in the right place. Good, you're going to implement the HP/UX ptrace interface on OpenBSD also. But even then it'll be HP/UX and OpenBSD specific. Why can't they inherit from inf-ptrace.c instead of adding ifdefs to this file? Isn't that the point of target inheritance - to avoid having code in the "base classes" which is only useful on a few targets? I considered doing this, but I didn't see a way to do this properly without violating two other "design principles": 1. The #ifdef PT_GET_PROCESS_STATE is essentially interleaved with the rest of the code. This is especially true for the fork following code that I didn't commit (yet). Seperating things would almost certainly lead to code duplication. 2. Creating a HP-UX and OpenBSD specific target vector would make autocomatic detection of the availibility of the necessary interfaces complicated. This is especially important for OpenBSD, where older versions don't have the necessary interfaces, and where we have an instantiation for the target vector for every supported hardware platform. So this: > @@ -471,6 +588,9 @@ inf_ptrace_target (void) > t->to_files_info = inf_ptrace_files_info; > t->to_kill = inf_ptrace_kill; > t->to_create_inferior = inf_ptrace_create_inferior; > +#ifdef PT_GET_PROCESS_STATE > + t->to_follow_fork = inf_ptrace_follow_fork; > +#endif > t->to_mourn_inferior = inf_ptrace_mourn_inferior; > t->to_thread_alive = inf_ptrace_thread_alive; > t->to_pid_to_str = normal_pid_to_str; This in particular makes me think it's in the wrong place. seems to be the right idiom from an autoconf standpoint. So instead of trying to go for OO purity, I took a more pragmatic approach. If you really think the interleaved #ifdefs are obfuscating the code, I think I can rework things a bit and create something a bit closer to seperate target vectors. But in order to avoid the problems in 1. and 2. I'd keep the stuff in inf-ptrace.c. Mark