From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15897 invoked by alias); 22 Oct 2002 21:43:30 -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 15890 invoked from network); 22 Oct 2002 21:43:29 -0000 Received: from unknown (HELO touchme.toronto.redhat.com) (216.138.202.10) by sources.redhat.com with SMTP; 22 Oct 2002 21:43:29 -0000 Received: from localhost.redhat.com (to-dhcp51.toronto.redhat.com [172.16.14.151]) by touchme.toronto.redhat.com (Postfix) with ESMTP id 9EA3C80007A; Tue, 22 Oct 2002 17:43:28 -0400 (EDT) Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 1BCA93EFF; Tue, 22 Oct 2002 17:43:27 -0400 (EDT) Message-ID: <3DB5C67E.9040700@redhat.com> Date: Tue, 22 Oct 2002 14:43:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.0) Gecko/20020824 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Michael Snyder , fnasser@redhat.com Cc: Daniel Jacobowitz , gdb-patches@sources.redhat.com Subject: Re: [RFA] Use vfork in shell_escape References: <20021022015205.GA22323@nevyn.them.org> <3DB5BAE9.2A01D78F@redhat.com> <20021022205654.GA10208@nevyn.them.org> <3DB5BC72.3DE58BD@redhat.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2002-10/txt/msg00430.txt.bz2 > Daniel Jacobowitz wrote: > >> >> On Tue, Oct 22, 2002 at 01:54:01PM -0700, Michael Snyder wrote: > >> > Daniel Jacobowitz wrote: > >> > > >> > > This patch is pretty obvious. I couldn't figure out why my machine was >> > > running out of memory; forking GDB to run an 'ls' during the maint.exp tests >> > > can be a bit heavy, since it may have all of glibc's debug info loaded. >> > > This patch seems logical to me... OK to commit? > >> > >> > Not as is. There's some auto-confery involved, since many systems >> > (some systems?) don't have vfork. Grep for vfork in fork-child.c. > >> >> Not as much as there used to be. But you're right, I goofed. OK with >> the addition of '#include "gdb_vfork.h"', which is all fork-child.c >> uses now? > > > For all I know, that's OK -- but I don't know. > I'll step back now, and wait for someone who does. Yep, from the ARI: HAVE VFORK #ifdef HAVE_VFORK is redundant. Include "gdb_vfork.h" and call vfork() unconditionally. Fernando - CLI? Andrew