Question about libffi closure

[Andrew Haley <aph at redhat dot com>]

Andreas Jaeger writes:
 > 
 > On AMD64 the closure tests all fail with a segmentation fauilt.  If
 > you look e.g. at closure_fn0 you'll see that the trampoline is setup
 > as:
 > 
 > 
 > The problem is that the trampoline is non-executable, the variables
 > are declared as static!  If I change the put cl on the stack instead
 > of static memory (removing the static keyword in line 48 of
 > closure_fn0.c), the test is successfull and returns the desired
 > argument:
 > 
 > $ LD_LIBRARY_PATH=../.libs/  ./closure_fn0.exe 
 > 1 2 3 4 127 429 7 8 9 10 11 12 13 19 21 1 3: 680
 > res: 680
 > 
 > My question now is is that test is really correct to allocate the
 > memory in static memory - and if it is correct, then how can this be
 > fixed?  Do other platforms have the same problem - and if not, what's
 > different?


It's not a problem, because gcj uses PROT_EXEC.

We can't change to stack allocation in general, because some targets
don't support executable stack.

The general solution is to use mmap().

Andrew.