On 10/12/2016 12:09 PM, David R. Hedges wrote: > For what it's worth, your example (and the resulting symptom) seem to > fall squarely in this undefined territory from the vfork manpage / POSIX > description: >> the behavior is undefined if the process created by vfork() [..] calls >> any other function before successfully calling [..] one of the exec(3) >> family of functions > > This doesn't solve your problem, but I wanted to make sure you're aware > of (and deliberately chose to accept) that.
I know what behavior the Linux kernel is producing, based on clone() flags. If I have to gratuitously call setjmp() and ignore its return value right before calling vfork() to beat reliable behavior out of gcc, I can do that. I can also use global variables instead of local variables, or make a structure of local variables so gcc can't gratuitously reorganize them and trim the stack, or have my one allowed <strike>phone</strike> function call be to a function I define that contains "everything the child does" to preserve the stack context. Personally, I'd rather the compiler didn't fight me when I'm trying to do something obvious, but I have LOTS of ways to fight back. :) Rob _______________________________________________ Toybox mailing list Toybox@lists.landley.net http://lists.landley.net/listinfo.cgi/toybox-landley.net