Re: Avoid ivopts when loop contains vfork

[Michael Matz <matz at suse dot de>]

Hi,

On Thu, 10 Feb 2011, Richard Guenther wrote:

> On Thu, Feb 10, 2011 at 3:31 PM, Bernd Schmidt <bernds@codesourcery.com> wrote:
> > When a loop contains vfork, certain loop optimizations can be incorrect.
> > This was seen with an unreleased port in the LTP testcase waitpid03,
> > with the relevant part of the code looking like this:
> >
> > Â Â Â Â Â Â Â while (++ikids < MAXUPRC) {
> > Â Â Â Â Â Â Â Â Â Â Â Âif ((pid[ikids] = FORK_OR_VFORK()) > 0) {
> >
> > This was transformed into an autoinc, i.e. something like
> >
> > Â Â Â Â Â Â Â while (ikids < MAXUPRC - 1) {
> > Â Â Â Â Â Â Â Â Â Â Â Âif ((pid[ikids++] = FORK_OR_VFORK()) > 0) {
> >
> > ikids did not get a hard register, which means that the copy on the
> > stack was incremented twice, once for each return from vfork.
> 
> Err, but isn't the stack copied by fork?

Yeah, but not by vfork.  Still the testcase is simply invalid, the _only_ 
things allowed after calling vfork is capturing the return value in a 
variable of type pid_t, calling exit, or calling exec*.  The above stores 
into a variable of type pid_t[] --> Invalid.

> It isn't obvious to me that IVOPTs can't handle returning twice 
> functions transparently (it has to consider us going into both arms of 
> the if anyways).

Right, it seems a sledge-hammer approach, and for a very general problem 
at that.  On OSes that implement vfork in the most restrictive sense (as 
in not separating the memory mappings), the compiler has to ensure that it 
doesn't store to any memory at all between the vfork/(exec|exit) sequence.  
For instance spills of the return value would be forbidden.  As long as we 
have those problems I don't see why we should change ivopts for an invalid 
testcase.


Ciao,
Michael.