Statement expression with function-call variable lifetime

Statement expression with function-call variable lifetime

[Shaun Jackman]

Hello,

I'm implementing a tiny vfork/exit implementation using setjmp and
longjmp. Since the function calling setjmp can't return (if you still
want to longjmp to its jmp_buf) I implemented vfork using a statement
expression macro. Here's my implementation of vfork.

jmp_buf *vfork_jmp_buf;
#define vfork() ({ \
	int setjmp_ret; \
	jmp_buf *prev_jmp_buf = vfork_jmp_buf, new_jmp_buf; \
	vfork_jmp_buf = &new_jmp_buf; \
	if( (setjmp_ret = setjmp(*vfork_jmp_buf)) != 0 ) \
		vfork_jmp_buf = prev_jmp_buf; \
	setjmp_ret; \
})

Unfortunately, after tracing a nasty bug I found that the same problem
applies to leaving a statement expression as does returning from a
function. The storage allocated for prev_jmp_buf and new_jmp_buf is
unallocated as soon as we leave the scope of the statement expression.
gcc quickly reuses that stack space later in the same function,
overwriting the saved jmp_buf. Does anyone have a suggestion how I can
allocate some storage space here for prev_jmp_buf and new_jmp_buf that
will last the lifetime of the function call instead of the lifetime of
the statement expression macro? My best idea was to use alloca, but it
wouldn't look pretty. Can someone confirm that memory allocated with
alloca would last the lifetime of the function call, and not the
lifetime of the statement expression?

Please cc me in your reply. Thanks,
Shaun

Re: Statement expression with function-call variable lifetime

[Daniel Jacobowitz]

On Wed, Jun 29, 2005 at 10:34:20AM -0700, Shaun Jackman wrote:
> the statement expression macro? My best idea was to use alloca, but it
> wouldn't look pretty. Can someone confirm that memory allocated with
> alloca would last the lifetime of the function call, and not the
> lifetime of the statement expression?

Yes, that's correct (and the only way to do this).

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: Statement expression with function-call variable lifetime

[Shaun Jackman]

On 6/29/05, Daniel Jacobowitz <drow@false.org> wrote:
> On Wed, Jun 29, 2005 at 10:34:20AM -0700, Shaun Jackman wrote:
> > the statement expression macro? My best idea was to use alloca, but it
> > wouldn't look pretty. Can someone confirm that memory allocated with
> > alloca would last the lifetime of the function call, and not the
> > lifetime of the statement expression?
> 
> Yes, that's correct (and the only way to do this).

Great! I've rewritten the vfork macro to use alloca. Here's the big
catch, the pointer returned by alloca is stored on the stack, and it
gets trashed upon leaving the statement expression. Where can I store
the pointer returned by alloca? Please don't say allocate some memory
for the pointer using alloca. <evil grin> My best idea so far was to
make the pointer returned by alloca (struct context *c, see below)
static, so that each time the macro is invoked, a little static memory
is put aside for it. I think this would work, but it doesn't seem to
me to be the best solution.

Here's the revised vfork macro that uses alloca:

jmp_buf *vfork_jmp_buf;

struct context {
	jmp_buf *prev_jmp_buf;
	jmp_buf new_jmp_buf;
};

# define vfork() ({ \
	int setjmp_ret; \
	struct context *c = alloca(sizeof *c); \
	c->prev_jmp_buf = vfork_jmp_buf; \
	vfork_jmp_buf = &c->new_jmp_buf; \
	if( (setjmp_ret = setjmp(*vfork_jmp_buf)) != 0 ) \
		vfork_jmp_buf = c->prev_jmp_buf; \
	setjmp_ret; \
})

Cheers,
Shaun

Re: Statement expression with function-call variable lifetime

[Russell Shaw]

Shaun Jackman wrote:
> Hello,
> 
> I'm implementing a tiny vfork/exit implementation using setjmp and
> longjmp. Since the function calling setjmp can't return (if you still
> want to longjmp to its jmp_buf) I implemented vfork using a statement
> expression macro. Here's my implementation of vfork.
> 
> jmp_buf *vfork_jmp_buf;
> #define vfork() ({ \
> 	int setjmp_ret; \
> 	jmp_buf *prev_jmp_buf = vfork_jmp_buf, new_jmp_buf; \
> 	vfork_jmp_buf = &new_jmp_buf; \
> 	if( (setjmp_ret = setjmp(*vfork_jmp_buf)) != 0 ) \
> 		vfork_jmp_buf = prev_jmp_buf; \
> 	setjmp_ret; \
> })
> 
> Unfortunately, after tracing a nasty bug I found that the same problem
> applies to leaving a statement expression as does returning from a
> function. The storage allocated for prev_jmp_buf and new_jmp_buf is
> unallocated as soon as we leave the scope of the statement expression.
> gcc quickly reuses that stack space later in the same function,
> overwriting the saved jmp_buf. Does anyone have a suggestion how I can
> allocate some storage space here for prev_jmp_buf and new_jmp_buf that
> will last the lifetime of the function call instead of the lifetime of
> the statement expression macro? My best idea was to use alloca, but it
> wouldn't look pretty. Can someone confirm that memory allocated with
> alloca would last the lifetime of the function call, and not the
> lifetime of the statement expression?
> 
> Please cc me in your reply. Thanks,
> Shaun

Alloca is like creating a stack variable, except it just gives you some
generic bytes that don't mean anything. Exiting the local scope will
trash the local variables and anything done with alloca(). You'll need
to store some information in a global variable. This C exceptions method
stores things as a linked list in nested stack frames and keeps a pointer
to the list in a global variable. Well worth studying:

   http://ldeniau.home.cern.ch/ldeniau/html/exception/exception.html

Re: Statement expression with function-call variable lifetime

[Shaun Jackman]

On 6/29/05, Russell Shaw <rjshaw@netspace.net.au> wrote:
> Alloca is like creating a stack variable, except it just gives you some
> generic bytes that don't mean anything. Exiting the local scope will
> trash the local variables and anything done with alloca(). You'll need
> to store some information in a global variable. This C exceptions method
> stores things as a linked list in nested stack frames and keeps a pointer
> to the list in a global variable. Well worth studying:
> 
>    http://ldeniau.home.cern.ch/ldeniau/html/exception/exception.html

Thanks! That linked was a very good reference. Here's the new and
improved vfork macro. It works nicely! If anyone's curious enough, I
can post the exit and waitpid macros that accompany it. I'm using
these macros to implement a Busybox system that does not need a fork
system call.

Thanks for all your help, Daniel and Russell! Cheers,
Shaun

struct vfork_context {
	struct vfork_context *prev;
	jmp_buf jmp;
} *vfork_context;

# define vfork() ({ \
	int setjmp_ret; \
	struct vfork_context *c = alloca(sizeof *c); \
	c->prev = vfork_context; \
	vfork_context = c; \
	if( (setjmp_ret = setjmp(c->jmp)) != 0 ) \
		vfork_context = vfork_context->prev; \
	setjmp_ret; \
})