GCC uses trampolines to handle addresses of nested functions. This is a method that allows you to avoid passing a static link of a nested function as a separate (but hidden) arg.

(For the benefit of people who don't know this technique) Consider: int f(int(*p)(int), int x) { return p(2*x); } int g(int a) { int b; int h(int c) { return b + c; } b = a*a; return f(&h, 2); } int i(int d) { return f(&g, 2); }

Here h is a function nested within g. When g is called, it calls h and passes it the address of h. When h is called from f, it must have access to locals in the containing g's frame. Normally you'd passed a hidden static link (address of g's frame). Alternately you can construct a trampoline function on the stack and pass its address (compile the above example and see for yourself). Since this function is created at runtime, it has the necessary information to provide the right static link before calling g. By putting it on the stack it is removed upon return from g (i.e. no need to garbage collect it).

For details please see gcc.info and http://master.debian.org/~karlheg/Usenix88-lexic.pdf

I don't know if other compilers use this technique. You should ask on comp.lang.{lisp,scheme,functional,ada,pascal,misc,...} before going ahead with this change.

In any case, IMHO you are patching the wrong thing. Any time you have more user mode threads than the kernel supplied ones, you can't say anything about where the actual stack is (since the stack switching must be done in user mode and the kernel can't play any stack segment switching games). Also, with threads there is not much point in having a stack segment that grows downward since threads may die in any order. As an example I have a simulation core where I can create as many threads as I want subject to memory limits (100K+ is no problem). I simply malloc() the stack for each thread. The point being, if you don't want an executable stack you must also not allow executable data segment since for a threaded program that is where a stack may be. This *will* contrain LISP + functional languages which create function closures on the fly or increase the cost of such function closure a lot.

-- bakul

To Unsubscribe: send mail to majo...@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message