[gambit-list] os_dyn
Marc Feeley
feeley at iro.umontreal.ca
Tue Oct 6 10:51:36 EDT 2009
On 6-Oct-09, at 8:37 AM, Michele Zaffalon wrote:
>> It is quite probable that OpenBSD forbids executing code in the C
>> heap, for
>> security reasons I guess. Usually there is a way to tell the
>> operating
>> system that a certain range of addresses contains executable code.
>> I have
>> no clue what this is on OpenBSD. If you do find out or someone on
>> the list
>> knows, please let me know.
>
> Is this the only way to have a Scheme defined function passed on the
> fly to C? Short of using global variables as in here
> https://mercure.iro.umontreal.ca/pipermail/gambit-list/2009-January/002939.html
Well, the only solutions I find acceptable. There might be some (more
or less portable) library to implement C closures that could be used
(libffi?). You have to understand what the fundamental problem is.
In C, functions pointers are implemented (usually) as the address of
the code which implements the function. The C compiler generates a
"call" instruction to that address. Scheme closures carry with them
an environment... that is what makes them more useful than plain
functions. So to convert a Scheme closure to a C function pointer, in
general it is necessary to allocate a fresh code address that will
correspond to the Scheme closure. The technique shown in the message
linked above is based on the idea of allocating at compile time a pool
of C functions, and then to assign them on demand to Scheme closures.
It is 100% portable, but it places a static limit on the number of
Scheme closures that can be converted (the code could be improved to
un-assign the Scheme closure when it is no longer live using wills for
example). The other solution, based on dynamic code generation, does
not place a limit on the number of converted Scheme closures, but it
is not portable (it is CPU and OS dependent). There is no portable
solution I know of that solves both issues (portable here means it
respects the C standard and only relies on the C standard).
Marc
More information about the Gambit-list
mailing list