[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <EE05C8D2-3BE1-416B-9AC8-BCC00B2A8607@uClinux.org>
Date: Fri, 12 Jun 2015 15:46:11 +0900
From: "D. Jeff Dionne" <jeff@...inux.org>
To: Rich Felker <dalias@...c.org>
Cc: "D. Jeff Dionne" <jeff@...inux.org>,
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 Jun 12, 2015, at 3:37 PM, Rich Felker <dalias@...c.org> 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.
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.
