From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7929 Path: news.gmane.org!not-for-mail From: "D. Jeff Dionne" Newsgroups: gmane.linux.lib.musl.general Subject: Re: Moving forward with sh2/nommu Date: Fri, 12 Jun 2015 15:46:11 +0900 Message-ID: References: <20150601151107.GA20759@brightrain.aerifal.cx> <20150610033050.GS17573@brightrain.aerifal.cx> <5579085B.5090407@landley.net> <20150611151252.GW17573@brightrain.aerifal.cx> <20150611172227.GY17573@brightrain.aerifal.cx> <87mw055z74.wl-ysato@users.sourceforge.jp> <20150612043555.GD17573@brightrain.aerifal.cx> <4817AF88-3C84-4EE1-A043-99D498B59A87@uClinux.org> <20150612063744.GE17573@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (Mac OS X Mail 8.2 \(2098\)) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1434091653 3535 80.91.229.3 (12 Jun 2015 06:47:33 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Jun 2015 06:47:33 +0000 (UTC) Cc: "D. Jeff Dionne" , Yoshinori Sato , "musl@lists.openwall.com" , "shumpei.kawasaki@swhwc.com" To: Rich Felker Original-X-From: musl-return-7942-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jun 12 08:47:32 2015 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1Z3IkV-0007i5-61 for gllmg-musl@m.gmane.org; Fri, 12 Jun 2015 08:47:31 +0200 Original-Received: (qmail 31938 invoked by uid 550); 12 Jun 2015 06:47:29 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: Original-Received: (qmail 31751 invoked from network); 12 Jun 2015 06:46:50 -0000 X-Virus-Scanned: Debian amavisd-new at mail.anifirmware.com In-Reply-To: <20150612063744.GE17573@brightrain.aerifal.cx> X-Mailer: Apple Mail (2.2098) Xref: news.gmane.org gmane.linux.lib.musl.general:7929 Archived-At: > On Jun 12, 2015, at 3:37 PM, Rich Felker wrote: >> >> This is not a nommu uClinux thing, it is a restriction we inherited >> from BSD vfork(). It makes things much simpler (read: tractable at >> all), actually. > > I'm not talking about returning from the function that called vfork. > This is about returning from vfork itself, to the caller of vfork. >>> The first return >>> (in the child) would properly restore these registers, but subsequent >>> execution in the child (in the function that called vfork, e.g. when >>> it sets up the stack for a call to execl) could clobber the locations >>> where they were saved on the stack, and when the parent resumed >>> execution, it vfork would restore the wrong values, and very bad >>> things could happen in the caller Oh, I see what you were saying, sorry about that. You are correct, there can be no C stack frame for vfork(), I agree. Cheers, J.