Clifford Wolf wrote:
If you have only one procesor stack (i.e. single-threaded execution), you can handle
hmm.. what's about doing it gc-like. Instead of a stack there simply is a 'pool' of trampolines from which trampolines are allocated and a pointer to the trampoline is pushed on the stack.
When the last trampoline from the pool is allocated, a 'garbage collector' is running over it and looking for pointers to trampolines between the stack pointer and the stack start address. Every trampoline which isn't possibly referenced is added to a free-list from which new trampolines are allocated.
the trampolines as a stack too. You don't need to deallocate till you allocate again,
and then you adjust the trampoline stack so none of its static chain pointers points to
a deallocated frame, or to the current frame (since you are only about to set up the
trampolines for the current frame then).
If you have multiple processor stacks, you have to register and later search them all in
order to make the garbage-collection scheme work.
that it doesn't point at any deallocated frames.
Instead of adding the trampoline pool to libgcc (as suggested earlier inYou don't need a linkonce section for this. The function that needs a trampoline
this thread) I would suggest that gcc generates a trampoline pool in a
linkonce section every time a source file is compiled which requires
trampolines. That way there wouldn't be any trampoline pool in an
executeable which doesn't need one
calls allocation / deallocation functions, or if it inlines the code, it will reference
the pool start addresses - either way, it will reference some symbols. By putting the
.o file that provides these symbols along with the code and data parts of the trampoline
pool into a static library - libgcc.a or otherwise - you make sure that the object is only
linked in when needed.
This is messy; say you have two libraries that are compiled with -ftrampoline-pool-size=32 ;and a compiler option such as -ftrampoline-pool-size=32 could be used the specify the size of the trampoline pool on the command line.
they will then share a trampoline pool of 32 entries. If you compile one with
-ftrampoline-pool-size=16 instead, you will have them using different pools, or maybe
even get some multiply defined symbols.
It is much saner to make this a link time option. By selecting a specific library for the
trampoline pool, you can adjust the size on a program (or dso, you you don't export)
basis, and you might even choose an alternate allocation strategy. I.e. you could have
libgcc provide one with a size that works most of the time and uses destructors for
portabiliyt and robustness, have a specialized lightweight one you can specifically use for
single-threaded programs, and have a 64 bit linux specific one that ties into the threading code
(or is part of a threads package) and mmaps trampoline code pages for every processor stack
allocated, sufficiently large and at a fixed offset to the stack so that you can put the data part
on the return stack in any suitably aligned position, and have a matching trampoline.
I.e. the bare function address and the static chain pointer are 8 bytes each, so that a trampoline
data part is 16 bytes. You require them to be 16-byte aligned on any processor stack.
The mmapped trampoline can be an absolute function call to some helper code that does the
real work, using the return address to figure out which trampoline is executed. This call should
fit into 16 bytes too, so in the trampoline page to be mmapped , every 16 bytes there is such an
absolute call insn. You can get a 1:1 correspondence between trampolines and processor stacks
by allocating the stacks all in one specific memory area, and have an equally-sized area where
trampolines are mapped. Thus, you can have differently-sized stacks, yet the trampoline code
can add a constant offset to the return address to find the data part of the trampoline.
