Re: Moving forward with sh2/nommu

[Rich Felker <dalias@libc.org>]

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@libc.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