This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]