From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7925 Path: news.gmane.org!not-for-mail From: Yoshinori Sato Newsgroups: gmane.linux.lib.musl.general Subject: Re: Moving forward with sh2/nommu Date: Fri, 12 Jun 2015 13:26:55 +0900 Message-ID: <87mw055z74.wl-ysato@users.sourceforge.jp> 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> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (generated by SEMI-EPG 1.14.7 - "Harue") Content-Type: text/plain; charset=US-ASCII X-Trace: ger.gmane.org 1434083336 25328 80.91.229.3 (12 Jun 2015 04:28:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Jun 2015 04:28:56 +0000 (UTC) Cc: musl@lists.openwall.com, "D. Jeff Dionne" , shumpei.kawasaki@swhwc.com To: Rich Felker Original-X-From: musl-return-7938-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jun 12 06:28:56 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 1Z3GaN-0004jb-6j for gllmg-musl@m.gmane.org; Fri, 12 Jun 2015 06:28:55 +0200 Original-Received: (qmail 32393 invoked by uid 550); 12 Jun 2015 04:28:53 -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 30632 invoked from network); 12 Jun 2015 04:27:08 -0000 X-Virus-Scanned: Debian amavisd-new at sa76r4.localdomain In-Reply-To: <20150611172227.GY17573@brightrain.aerifal.cx> User-Agent: Wanderlust/2.15.9 (Almost Unreal) SEMI-EPG/1.14.7 (Harue) FLIM/1.14.9 (=?ISO-8859-4?Q?Goj=F2?=) APEL/10.8 EasyPG/1.0.0 Emacs/24.4 (x86_64-pc-linux-gnu) MULE/6.0 (HANACHIRUSATO) Xref: news.gmane.org gmane.linux.lib.musl.general:7925 Archived-At: On Fri, 12 Jun 2015 02:22:27 +0900, Rich Felker wrote: > > On Thu, Jun 11, 2015 at 11:12:52AM -0400, Rich Felker wrote: > > > >> 3. We need sh/vfork.s since the default vfork.c just uses fork, which > > > >> won't work. I have a version locally but it doesn't make sense to > > > >> commit without runtime trap number selection. > > > > > > > > Done and updated to use runtime selection in the (ugly) patch. > > > > > > If they ask for vfork() they should get vfork()...? > > > > Yes. The "runtime selection" is about the syscall trap number, not > > whether or not to use vfork. I committed vfork to upstream musl now, > > but with a SH3/4 trap number to be consistent with the code that's > > upstream now. Later I'll either convert them all to trap 31 (0x1f) if > > that ends up being acceptable, or merge the runtime-selection code, > > but I think it makes sense to make the change across all files at > > once, whichever way it's done. > > Ah, maybe I misunderstood. If you were asking abaout the original > remark that the default vfork.c uses fork, the reason is simply that > you can't write vfork() in C. The return from vfork() in the child > will clobber vfork's stack frame, which may contain the return address > or saved registers, and then when the parent resumes, very bad things > will happen. vfork() has to be implemented in asm to ensure that any > state it needs to be able to return in the parent is kept in registers > rather than memory. Thus, each arch needs an arch-specific version, > and we just hadn't gotten around to adding the sh version yet. > > Rich No. vfork kept only last return address. It isn't necessary to preserve the value of anything but that. Child process can't return caller routine. -- Yoshinori Sato