[Vm-dev] Exporting module symbols on windows

Igor Stasenko siguctua at gmail.com
Tue Feb 12 08:33:01 UTC 2013


On 11 February 2013 20:56, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>
>
>
> On Sun, Feb 10, 2013 at 4:52 AM, Igor Stasenko <siguctua at gmail.com> wrote:
>>
>>
>> On 10 February 2013 01:51, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> >
>> >
>> >
>> > On Sat, Feb 9, 2013 at 3:18 PM, Igor Stasenko <siguctua at gmail.com> wrote:
>> >>
>> >>
>> >> Hi, Eliot
>> >>
>> >> i thought about it, and i don't like it.
>> >> I am in favor of exporting stuff explicitly, rather than implicitly by
>> >> compiler..
>> >> because with implicit exports, you never know whether given symbol
>> >> will be visible or not..
>> >> and you have to guess and hope instead of being confident.
>> >>
>> >> It would be nice if we could have a way to export all functions and variables
>> >> which has <api> pragma.. because exporting everything , first is not
>> >> needed, second
>> >> it will expose some symbols which are really private to VM which is
>> >> not very good from design perspective.
>> >
>> >
>> > I agree. All you need to do on WIndows is to collect all the functions that are either marked as api, export: true or in requiredMethodNames and write a .def file.  The syntax of the def file is easy enough (just a list of names IIRC) that a Makefile could munge it to produce a set of flags for a linker (but it's a *lot* of flags :) ).  You might look at where the CodeGenerator produces cointerp.h and cogit.h and add the generation there.
>> >
>>
>> There's already support for that in codebase
>> all we need is to use  __declspec( dllexport )  as recommended in [1].
>>
>> (btw, it is already used by EXPORT() macro,
>> but this macro suitable only for declarations with known return type
>> (btw why?), so i took a freedom to add a new)..
>
>
> Yes, but this overloads the export pragma.  <export: true> in a primitive method means add it to the set of primitives in the containing module (interpreter or plugin).  Whereas you want something that makes a symbol available to lookup its address via an FFI's introspection facilities.  Further, the export pragma applies only to functions and one needs to be able to make variables visible.  So it looks to me that these two uses don't overlap.
>

> One solution is to make all non-static symbols visible (which is what happens currently on Mac and Linux) and could easily be adapted to WIndows.
> Another solution is to add some other metadata (there's already mustBeGlobal: for variables, which again doesn't mean make visible to the FFI, it means make available to the platform subsystem at link time).  Part of the problem is which symbols to export, and part of the problem is what for.  The FFI/NB introspection isn't for a specific purpose; its to build whatever one might want to build.  So exporting everything is a better default than exporting that which is already marked as export (because export: true doesn't mean "export for the FFI").
>
> Personally I think the most rational thing to do is to make all symbols available and provide security (as is the current model) by not providing the introspection facilities that allow one to look for the symbols; i.e. deploy without FFI, NB et al.
>
yes.. it is hard to choose what to export and what not.
Right now i think i will go with this patch.. it exposes variables and
functions from headers..
so no harm.

-- 
Best regards,
Igor Stasenko.


More information about the Vm-dev mailing list