From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31920 invoked by alias); 23 Nov 2004 22:17:11 -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 31866 invoked from network); 23 Nov 2004 22:17:04 -0000 Received: from unknown (HELO walton.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org with SMTP; 23 Nov 2004 22:17:04 -0000 Received: from elgar.sibelius.xs4all.nl (elgar.sibelius.xs4all.nl [192.168.0.2]) by walton.sibelius.xs4all.nl (8.13.0/8.13.0) with ESMTP id iANMH3Mx003478 for ; Tue, 23 Nov 2004 23:17:03 +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 iANMH3s0014458 for ; Tue, 23 Nov 2004 23:17:03 +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 iANMH3F9014455; Tue, 23 Nov 2004 23:17:03 +0100 (CET) Date: Tue, 23 Nov 2004 22:17:00 -0000 Message-Id: <200411232217.iANMH3F9014455@elgar.sibelius.xs4all.nl> From: Mark Kettenis To: gdb-patches@sources.redhat.com Subject: [RFC] To fork or to vfork X-SW-Source: 2004-11/txt/msg00456.txt.bz2 It's now pretty clear to me why HP-UX 11.xx needs -Dvfork=fork. In order to set up a child to be traced using the HP-UX ttrace(2) system call, it needs to do some handshaking. It uses two pipes to do this. The child writes to one end to indicate that it's ready to be traced. When the parent is able to read from the other end it will set things up such that the child is properly traced. It then indicates that the child may continue by writing on the other pipe. However, since the parent is suspended while the child is in the vforked state, this doesn't work, and the debugger hangs. Now I think we all agree that the -Dvfork=fork is pretty ugly. Here's an alternate approach. It's pretty likely that if PRE_TRACE_FUN is non-null things are complicated enough that it's unlikely that a vfork will work correctly. I therefore propose the attached patch. If there are no objections, I'll check this in in a few days. Mark Index: ChangeLog from Mark Kettenis * fork-child.c (fork_inferior): Fork instead of vfork if PRE_TRACE_FUN is non-null. Index: fork-child.c =================================================================== RCS file: /cvs/src/src/gdb/fork-child.c,v retrieving revision 1.23 diff -u -p -r1.23 fork-child.c --- fork-child.c 30 Sep 2004 20:15:39 -0000 1.23 +++ fork-child.c 23 Nov 2004 22:15:03 -0000 @@ -274,10 +274,18 @@ fork_inferior (char *exec_file_arg, char if (pre_trace_fun != NULL) (*pre_trace_fun) (); - /* Create the child process. Note that the apparent call to vfork() - below *might* actually be a call to fork() due to the fact that - autoconf will ``#define vfork fork'' on certain platforms. */ - if (debug_fork) + /* Create the child process. Since the child process is going to + exec(3) shortlty afterwards, try to reduce the overhead by + calling vfork(2). However, if PRE_TRACE_FUN is non-null, it's + likely that this optimization won't work since there's too much + work to do between the vfork(2) and the exec(3). This is known + to be the case on ttrace(2)-based HP-UX, where some handshaking + between parent and child needs to happen between fork(2) and + exec(2). However, since the parent is suspended in the vforked + state, this doesn't work. Also note that the vfork(2) call might + actually be a call to fork(2) due to the fact that autoconf will + ``#define vfork fork'' on certain platforms. */ + if (pre_trace_fun || debug_fork) pid = fork (); else pid = vfork ();