This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH] [BZ #18433] Check file access/existence before forking.


On Fri, Sep 18, 2015 at 11:19:56PM +0300, Alexander Monakov wrote:
> On Fri, 18 Sep 2015, Rich Felker wrote:
> > > > i think all use of vfork is invalid c: the compiler can
> > > > spill registers on the stack then in the child clobber
> > > > them, then after vfork returns in the parent the
> > > > clobbered registers are restored breaking the expectations
> > > > of the compiler. (this can break independently of how
> > > > the c code around vfork looks like).
> > > 
> > > The same argument applies to setjmp,
> > 
> > Not quite. With setjmp, once there's any return from the function
> > where setjmp was called (or call to a function that's known neither to
> > return nor call longjmp or throw an exception), the compiler may
> > rightfully assume that non-reachable data in the setjmp caller is no
> > longer live and clobber it.
> > 
> > What makes vfork is special is that the data must be treated as live
> > even when the caller calls _exit.
> 
> For the compiler, the relationship between vfork and _exit should be the same
> as between setjmp and longjmp: calling the latter causes the former to return
> a second time.

Yes, I suppose that's a good way to model it. But the returns_twice
attribute does not specify under what conditions the function returns
again, so unless gcc has vfork-specific knowledge attached to the
specific name, I suppose it must just assume everything stays live.

Rich


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]