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. :)

Toybox mailing list

Reply via email to