From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1728 invoked by alias); 10 Mar 2004 17:02:04 -0000 Mailing-List: contact libc-hacker-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-hacker-owner@sources.redhat.com Received: (qmail 1710 invoked from network); 10 Mar 2004 17:02:03 -0000 Received: from unknown (HELO sunsite.ms.mff.cuni.cz) (195.113.19.66) by sources.redhat.com with SMTP; 10 Mar 2004 17:02:03 -0000 Received: from sunsite.ms.mff.cuni.cz (sunsite.mff.cuni.cz [127.0.0.1]) by sunsite.ms.mff.cuni.cz (8.12.8/8.12.8) with ESMTP id i2AEornd023875; Wed, 10 Mar 2004 15:50:53 +0100 Received: (from jakub@localhost) by sunsite.ms.mff.cuni.cz (8.12.8/8.12.8/Submit) id i2AEoqKM023873; Wed, 10 Mar 2004 15:50:53 +0100 Date: Wed, 10 Mar 2004 17:02:00 -0000 From: Jakub Jelinek To: davidm@hpl.hp.com Cc: Andreas Schwab , Ulrich Drepper , Glibc hackers Subject: Re: [PATCH] getpid/vfork/raise fix Message-ID: <20040310145052.GX3822@sunsite.ms.mff.cuni.cz> Reply-To: Jakub Jelinek References: <404BDA36.6000202@redhat.com> <200403080237.i282bXG6004322@magilla.sf.frob.com> <20040308110105.GN3822@sunsite.ms.mff.cuni.cz> <404D76CA.4010500@redhat.com> <20040309115038.GO3822@sunsite.ms.mff.cuni.cz> <20040310101515.GS3822@sunsite.ms.mff.cuni.cz> <16463.17524.280448.143159@napali.hpl.hp.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <16463.17524.280448.143159@napali.hpl.hp.com> User-Agent: Mutt/1.4i X-SW-Source: 2004-03/txt/msg00050.txt.bz2 On Wed, Mar 10, 2004 at 08:38:12AM -0800, David Mosberger wrote: > >>>>> On Wed, 10 Mar 2004 15:33:05 +0100, Andreas Schwab said: > > Andreas> That doesn't seem to work, though. I'm getting p3 != p4 in > Andreas> the posix vfork tests. Or do you see any error in my > Andreas> implementation? > > Most scratch registers are _not_ preserved across system calls. You > could spill the register onto the memory stack though. If it uses at > most 16 bytes, you won't have to adjust the stack pointer even. But as soon as you spill something into memory the vfork child can clobber it and you restore in the parent something different from what you saved. Jakub