This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Questions about trampolines
- From: Waldek Hebisch <hebisch at math dot uni dot wroc dot pl>
- To: Robert Dewar <dewar at adacore dot com>
- Cc: Waldek Hebisch <hebisch at math dot uni dot wroc dot pl>, gcc at gcc dot gnu dot org
- Date: Mon, 14 Mar 2005 23:24:41 +0100 (CET)
- Subject: Re: Questions about trampolines
Robert Dewar wrote:
> Waldek Hebisch wrote:
>
> > But there is no need to generate trampolines on the stack. Namely,
> > one can generate code in a separate area. In C this causes problems
> > with garbage collection, which IMHO can be solved, but requre alloca-like
> > tricks. On the other hand trampolines in separate area may provide
> > extra functionality, beyond what nested functions give. For example
> > they can be used to "partially apply" a function, giving it some
> > frozen arguments, and providing the rest at call time.
>
> Trampolines do of course have to be handled in a stack like fashion (to
> get recursion right), so you have to be very careful about allocation and
> deallocation in this separate area. And you still have the cache problem,
> so I don't see what it buys.
>
1) the stack can be execute protected, so simple buffer overflow exploits
will be detected. On i386 one can use segment register to make stack
non-executable and still use trampolines
2) On machine with separate code and data areas trampolines can be in
(writable) code space. Of course it does not help if all code space
in non-writable.
3) One limits contention between code and data cache during calls. Of
course cost of generating trampoline may be slightly higher, but the
cost of call is likely to be lower. Even for for generation, one can
limit number of `mprotect' call from one per tramoline to one per page
(which is likely to be much smaller).
4) One gets extra functionality (partial application), which may
significanlty reduce need for pointers to nested functions. Namely,
trampolines for partial application may be re-used much easier
then nested functions (which have to be regenerated when entering
the scope)
--
Waldek Hebisch
hebisch@math.uni.wroc.pl