Marco Gerards <mgerards@xxxxxxxxx> writes: > Sorry, I should choose my words more carefully. Are nested functions > being deprecated? No. Nested function support is required in any case to support languages other than C/C++. Given that the backend support is required, there is no particular plan to remove the extension from C/C++. > Are there plans to use something else than an > executable stack to implement trampolines? Not I am aware of. Efficient, general, trampolines require the ability to generate code on the fly. That requires a section of memory which is both writable and executable. It doesn't have to be the stack, but in general any approach along those lines is going to run afoul of people concerned about security holes. The basic problem, of course, is that taking the pointer of a nested function requires storing both a code address (the function) and a data address (the stack frame). But a function pointer in a normal C implementation is only a code address. If all you have is a code address, where do you store the data address? One possibility would be to provide a fixed number of trampolines which reference particular locations in memory. They would be allocated and deallocated based on stack usage. That would handle most real programs, but there would always be valid programs which would crash under this type of implementation. I'm not aware of anybody working on this type of implementation. (Something along these lines may be required to support trampolines on Harvard architectures, in which memory is by definition never both writable and executable.) Here is an approach that might work in the general case on a Unix system. When we need to create a trampoline, use mmap with PROT_WRITE to create a new anonymous page. Copy the trampoline template into it, and adjust it as required. Then use mprotect to remove PROT_WRITE and add PROT_EXEC. Then continue as usual. The obvious drawback is requiring two system calls for every trampoline you create. Other than that, I think it ought to work. I'm not aware of anybody working on this type of implementation either. Ian
