From owner-cvs-usrbin Fri Apr 25 11:47:39 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.5/8.8.5) id LAA03924 for cvs-usrbin-outgoing; Fri, 25 Apr 1997 11:47:39 -0700 (PDT) Received: from nagual.pp.ru (ache.relcom.ru [194.58.229.133]) by hub.freebsd.org (8.8.5/8.8.5) with ESMTP id LAA03917; Fri, 25 Apr 1997 11:47:32 -0700 (PDT) Received: (from ache@localhost) by nagual.pp.ru (8.8.5/8.8.5) id WAA05772; Fri, 25 Apr 1997 22:46:46 +0400 (MSD) Date: Fri, 25 Apr 1997 22:46:43 +0400 (MSD) From: =?KOI8-R?B?4c7E0sXKIP7F0s7P1w==?= To: Bruce Evans cc: cvs-all@freebsd.org, CVS-committers@freebsd.org, cvs-usrbin@freebsd.org Subject: Re: cvs commit: src/usr.bin/vacation vacation.c In-Reply-To: <199704251432.AAA00549@godzilla.zeta.org.au> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-cvs-usrbin@freebsd.org X-Loop: FreeBSD.org Precedence: bulk On Sat, 26 Apr 1997, Bruce Evans wrote: > NON_SAVING_SETJMP is for systems whose setjmp() doesn't save all the > registers, perhaps because the native compiler uses a caller-saved > convention so the native setjmp() doesn't need to. The native system > would have to use special handling for vfork(), one of the following: > > 1. save registers in vfork() and don't save before call (simplest). > 2. save registers before call and don't write to or free the save > area until the child exits (difficult in cases that may have > iterated vforks - if the stack is used then it can only be shrunk > if the compiler understands the flow of control well enough to > decide when the child returns!). Hmm, maybe I overlook something, but I not found gcc saving registers when NON_SAVING_SETJMP is on, it just mark them as clobbered to not use them later. Is it will be just enough for vfork? -- Andrey A. Chernov http://www.nagual.pp.ru/~ache/