Date: Fri, 12 Jun 2015 02:37:44 -0400 From: Rich Felker <dalias@...c.org> To: "uClinux.org" <Jeff@...inux.org> Cc: Yoshinori Sato <ysato@...rs.sourceforge.jp>, "musl@...ts.openwall.com" <musl@...ts.openwall.com>, "shumpei.kawasaki@...wc.com" <shumpei.kawasaki@...wc.com> Subject: Re: Moving forward with sh2/nommu On Fri, Jun 12, 2015 at 01:49:28PM +0900, uClinux.org wrote: > Rich, > > This isn't necessary. The child in a nommu system -must never- > return from the function that called vfork. The reason is there is > only one stack, and so that stack must not be corrupted (not the > pointer, the actual call frame) or 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. I'm not talking about returning from the function that called vfork. This is about returning from vfork itself, to the caller of vfork. Rich > > On Jun 12, 2015, at 13:35, Rich Felker <dalias@...c.org> wrote: > > > >> 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: > >>> > >>> 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. > >> > >> 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. > > > > 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). > > > > Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.