From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/7928 Path: news.gmane.org!not-for-mail From: "uClinux.org" Newsgroups: gmane.linux.lib.musl.general Subject: Re: Moving forward with sh2/nommu Date: Fri, 12 Jun 2015 13:49:28 +0900 Message-ID: <4817AF88-3C84-4EE1-A043-99D498B59A87@uClinux.org> 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> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 (1.0) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1434091092 26245 80.91.229.3 (12 Jun 2015 06:38:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 12 Jun 2015 06:38:12 +0000 (UTC) Cc: Yoshinori Sato , "musl@lists.openwall.com" , "shumpei.kawasaki@swhwc.com" To: Rich Felker Original-X-From: musl-return-7940-gllmg-musl=m.gmane.org@lists.openwall.com Fri Jun 12 08:38:05 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 1Z3IbM-0002tg-OE for gllmg-musl@m.gmane.org; Fri, 12 Jun 2015 08:38:04 +0200 Original-Received: (qmail 25843 invoked by uid 550); 12 Jun 2015 06:38:03 -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 14331 invoked from network); 12 Jun 2015 04:50:20 -0000 X-Virus-Scanned: Debian amavisd-new at mail.anifirmware.com In-Reply-To: <20150612043555.GD17573@brightrain.aerifal.cx> X-Mailer: iPhone Mail (11D257) Xref: news.gmane.org gmane.linux.lib.musl.general:7928 Archived-At: Rich, This isn't necessary. The child in a nommu system -must never- return from t= he function that called vfork. The reason is there is only one stack, and s= o that stack must not be corrupted (not the pointer, the actual call frame) o= r as you mention the parent cannot continue execution. 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. Cheers, J. > On Jun 12, 2015, at 13:35, Rich Felker wrote: >=20 >> On Fri, Jun 12, 2015 at 01:26:55PM +0900, Yoshinori Sato wrote: >> On Fri, 12 Jun 2015 02:22:27 +0900, >> Rich Felker wrote: >>>=20 >>> 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, whic= h >>>>>>> won't work. I have a version locally but it doesn't make sense to >>>>>>> commit without runtime trap number selection. >>>>>>=20 >>>>>> Done and updated to use runtime selection in the (ugly) patch. >>>>>=20 >>>>> If they ask for vfork() they should get vfork()...? >>>>=20 >>>> 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. >>>=20 >>> 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. >>=20 >> 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. >=20 > vfork still has to follow the normal function call ABI of preserving > call-saved registers. For example, if you (or the compiler) wrote > vfork by spilling some or all of the call-saved registers to the > stack, clobbering them (e.g. for stack-protector work, or profiling > counters, or PIC-related purposes, or for no reason at all), and then > restoring them at return time, you'd be in trouble. 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 (e.g. the GOT register used for > loading string literal args to exec*() might be wrong). >=20 > Rich