<br><br><div class="gmail_quote">On Sun, Feb 10, 2013 at 4:52 AM, Igor Stasenko <span dir="ltr"><<a href="mailto:siguctua@gmail.com" target="_blank">siguctua@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>On 10 February 2013 01:51, Eliot Miranda <<a href="mailto:eliot.miranda@gmail.com">eliot.miranda@gmail.com</a>> wrote:<br>
><br>
><br>
><br>
> On Sat, Feb 9, 2013 at 3:18 PM, Igor Stasenko <<a href="mailto:siguctua@gmail.com">siguctua@gmail.com</a>> wrote:<br>
>><br>
>><br>
>> Hi, Eliot<br>
>><br>
>> i thought about it, and i don't like it.<br>
>> I am in favor of exporting stuff explicitly, rather than implicitly by<br>
>> compiler..<br>
>> because with implicit exports, you never know whether given symbol<br>
>> will be visible or not..<br>
>> and you have to guess and hope instead of being confident.<br>
>><br>
>> It would be nice if we could have a way to export all functions and variables<br>
>> which has <api> pragma.. because exporting everything , first is not<br>
>> needed, second<br>
>> it will expose some symbols which are really private to VM which is<br>
>> not very good from design perspective.<br>
><br>
><br>
> 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.<br>
><br>
<br>
There's already support for that in codebase<br>
all we need is to use __declspec( dllexport ) as recommended in [1].<br>
<br>
(btw, it is already used by EXPORT() macro,<br>
but this macro suitable only for declarations with known return type<br>
(btw why?), so i took a freedom to add a new)..<br></blockquote><div><br></div><div>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.</div>
<div><br></div><div>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.</div><div>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").</div>
<div><br></div><div>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.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
- added VM_EXPORT macro<br>
in sq.h:<br>
<br>
#define VM_EXPORT /*nothing*/<br>
<br>
in win32/vm/sqPlatformSpecific.h:<br>
<br>
#undef VM_EXPORT<br>
#define VM_EXPORT __declspec( dllexport )<br>
<br>
(in both cases right under EXPORT() macro definition)<br>
<br>
- changed 3 methods in VMMaker, mainly to emit corresponding macros in<br>
.headers (see attached)<br>
<br>
i wonder, if it is syntactically correct to use<br>
EXPORT() macro e.g. without parameter.. then VM_EXPORT not needed since<br>
will be expanded into<br>
EXPORT(/*nothing*/) => __declspec( dllexport ) /*nothing*/<br>
<br>
<br>
And now running in windoze, i can do:<br>
<br>
NativeBoost loadSymbol: #CFramePointer fromModule: NativeBoost VMModule<br>
@ 16r5A5710<br>
<br>
or:<br>
NativeBoost loadSymbol: #suppressHeartbeatFlag fromModule: NativeBoost VMModule<br>
@ 16r5A56EC<br>
<br>
<br>
voila!<br>
<br>
<br>
[1] <a href="https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/4/html/Using_ld_the_GNU_Linker/win32.html" target="_blank">https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/4/html/Using_ld_the_GNU_Linker/win32.html</a><br>
<br>
<br>
--<br>
Best regards,<br>
Igor Stasenko.<br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br>best,<div>Eliot</div>