[Toybox] fun with vfork

Josh Gao jmgao at google.com
Thu Oct 13 01:25:05 PDT 2016


On Wed, Oct 12, 2016 at 5:49 PM, Rob Landley <rob at landley.net> wrote:
>
> So... no? I think? Is there a way _I_ can tag this? (I can't do my own
> vfork prototype because I can't #undef the one I get out of unistd.h and
> that's a fairly generic header. It's sad I can't redo function
> prototypes after the fact, but the language never gave me a way to.
> Maybe I could do a gratuitous wrapper around it?)
>

gcc seems to do the equivalent automatically for any function named
"vfork":
https://github.com/gcc-mirror/gcc/blob/e11be3ea01eaf8acd8cd86d3f9c427621b64e6b4/gcc/calls.c#L533

On Thu, Oct 13, 2016 at 1:03 AM, Rob Landley <rob at landley.net> wrote:
>
> 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. :)


It doesn't seem like gcc differentiates between vfork, setjmp, etc. so it's
presumably providing some behavior that satisfies the constraints of all of
them (or there's a bug). The specification for longjmp says that only
non-volatile local variables that get modified have unspecified values, so
you could maybe try sprinkling volatile on things to see if it makes your
problem go away?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.landley.net/pipermail/toybox-landley.net/attachments/20161013/dd8a6a0b/attachment.htm>


More information about the Toybox mailing list