some trampoline data

[Marc Espie <espie at nerim dot net>]

Okay, I've finally implemented a -ftrampolines flag in OpenBSD. The system
compiler in OpenBSD will not allow trampoline code generation without that
flag...

What's interesting is that exactly 0 port in the 3000 packages in the
OpenBSD port collection failed to build because of that flag.

Which mean that the use of local functions as closures really is not a big
gcc staple: looks like nobody sane uses that in production code.

This raises a few questions. In my opinion, the ada folks are the only
people who actually use this kind of feature actively, so they probably
should have a real say in the implementation (if I remember things right,
Robert Dewar mentioned that the trampoline implementation of local
functions was not efficient at all, and it would be better to have
generalized function pointers).

I'm also thinking it would make sense to have an -f flag allowing
trampoline code generation in mainline gcc.  Looking at this from a
security point of view, trampoline code generation is the *only* instance
in gcc (as in: C/C++ compiler) that builds code at runtime... which
introduces lots of caching issues/security risks (like enabling big chunks
of user memeory space to be executable on i386).

My quick survey of ~6GB of code seems to show it wouldn't be an 
issue for most people out there... and it would make people who use
trampolines aware of the issues involved.