[Vm-dev] Exporting module symbols on windows

[Eliot Miranda]

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.



> - added VM_EXPORT macro
>   in sq.h:
>
> #define VM_EXPORT  /*nothing*/
>
>   in win32/vm/sqPlatformSpecific.h:
>
> #undef VM_EXPORT
> #define VM_EXPORT __declspec( dllexport )
>
> (in both cases right under EXPORT() macro definition)
>
> - changed 3 methods in VMMaker, mainly to emit corresponding macros in
> .headers (see attached)
>
> i wonder, if it is syntactically correct to use
> EXPORT() macro e.g. without parameter.. then VM_EXPORT not needed since
> will be expanded into
> EXPORT(/*nothing*/) =>  __declspec( dllexport ) /*nothing*/
>
>
> And now running in windoze, i  can do:
>
>  NativeBoost loadSymbol: #CFramePointer fromModule: NativeBoost VMModule
>          @ 16r5A5710
>
> or:
>  NativeBoost loadSymbol: #suppressHeartbeatFlag fromModule: NativeBoost
> VMModule
>          @ 16r5A56EC
>
>
> voila!
>
>
> [1]
> https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/4/html/Using_ld_the_GNU_Linker/win32.html
>
>
> --
> Best regards,
> Igor Stasenko.
>
>


-- 
best,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20130211/47057c93/attachment.htm