#pragma export on/off

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
9 messages Options
Reply | Threaded
Open this post in threaded view
|

#pragma export on/off

Eliot Miranda-2
 
Hi All,

    anyone know what platform this pragma is aimed at, and whether we still really, really need it?  It is the source of the bulk of my warnings in the cog interpreter and I'd love to nuke it.

E.
Reply | Threaded
Open this post in threaded view
|

Re: #pragma export on/off

Brad Fowlow-2
 

I would guess Code Warrior (Mac OS < X)


> Hi All,
>
>     anyone know what platform this pragma is aimed at, and whether  
> we still really, really need it?  It is the source of the bulk of my  
> warnings in the cog interpreter and I'd love to nuke it.
>
> E.

Reply | Threaded
Open this post in threaded view
|

Re: #pragma export on/off

johnmci
In reply to this post by Eliot Miranda-2
 
http://publib.boulder.ibm.com/infocenter/zos/v1r9/index.jsp?topic=/com.ibm.zos.r9.cbclx01/pexport.htm

It's to expose the symbol names for routines so that FFI and the code  
loading logic can find the public API for internal plugins.


I'm not sure how it applies today, various newer versions of gcc 4.x  
cheerfully makes everything private unless told otherwise.
But I'll let Ian reply since I'm sure it still is required on some  
platforms.

On 19-Feb-09, at 7:42 PM, Eliot Miranda wrote:

> Hi All,
>
>     anyone know what platform this pragma is aimed at, and whether  
> we still really, really need it?  It is the source of the bulk of my  
> warnings in the cog interpreter and I'd love to nuke it.
>
> E.

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================



Reply | Threaded
Open this post in threaded view
|

Re: #pragma export on/off

Igor Stasenko
In reply to this post by Eliot Miranda-2
 
2009/2/20 Eliot Miranda <[hidden email]>:
>
> Hi All,
>     anyone know what platform this pragma is aimed at, and whether we still really, really need it?  It is the source of the bulk of my warnings in the cog interpreter and I'd love to nuke it.
> E.
>
+1 for nuking it :)
As i understand this pragma ensuring that given symbol will appear in
module exports table, so other modules could lookup this symbol and
call these functions directly.
I fail see how such functions could be called directly bypassing rules
which ensuring a level of safety for VM - like InterpreterProxy.



--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: #pragma export on/off

johnmci
 
Well the pattern used  is like so where we ask the operating system to  
find the entry point secCanRenameImage in the SecurityPlugin
which relies on the plugin either being external, or internal, and if  
the plugin actually has the secCanRenameImage.
This code enables weak linking....

                sCRIfn = ioLoadFunctionFrom("secCanRenameImage", "SecurityPlugin");
                if (sCRIfn != 0) {
                        okToRename =  ((sqInt (*)(void))sCRIfn)();
                        if (!(okToRename)) {
                                /* begin primitiveFail */
                                foo->successFlag = 0;
                                return null;
                        }
                }



On 19-Feb-09, at 7:52 PM, Igor Stasenko wrote:

>
> 2009/2/20 Eliot Miranda <[hidden email]>:
>>
>> Hi All,
>>    anyone know what platform this pragma is aimed at, and whether  
>> we still really, really need it?  It is the source of the bulk of  
>> my warnings in the cog interpreter and I'd love to nuke it.
>> E.
>>
> +1 for nuking it :)
> As i understand this pragma ensuring that given symbol will appear in
> module exports table, so other modules could lookup this symbol and
> call these functions directly.
> I fail see how such functions could be called directly bypassing rules
> which ensuring a level of safety for VM - like InterpreterProxy.
>
>
>
> --
> Best regards,
> Igor Stasenko AKA sig.

--
=
=
=
========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
=
=
=
========================================================================



Reply | Threaded
Open this post in threaded view
|

Re: #pragma export on/off

Eliot Miranda-2
In reply to this post by johnmci
 


On Thu, Feb 19, 2009 at 7:49 PM, John M McIntosh <[hidden email]> wrote:

http://publib.boulder.ibm.com/infocenter/zos/v1r9/index.jsp?topic=/com.ibm.zos.r9.cbclx01/pexport.htm

It's to expose the symbol names for routines so that FFI and the code loading logic can find the public API for internal plugins.


I'm not sure how it applies today, various newer versions of gcc 4.x cheerfully makes everything private unless told otherwise.
But I'll let Ian reply since I'm sure it still is required on some platforms.

Remember the EXPORT macro exists also.  So if it can be done via the EXPORT pragma then we should nuke the export pragma.
 


On 19-Feb-09, at 7:42 PM, Eliot Miranda wrote:

Hi All,

   anyone know what platform this pragma is aimed at, and whether we still really, really need it?  It is the source of the bulk of my warnings in the cog interpreter and I'd love to nuke it.

E.

--
===========================================================================
John M. McIntosh <[hidden email]>
Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
===========================================================================




Reply | Threaded
Open this post in threaded view
|

Re: #pragma export on/off

Eliot Miranda-2
In reply to this post by Brad Fowlow-2
 


On Thu, Feb 19, 2009 at 7:46 PM, brad fowlow <[hidden email]> wrote:


I would guess Code Warrior (Mac OS < X)

Then at least in Cog I'm leaning towards nuking it.  I don't see Cog ever being ported to pre Mac OS X PowerPC Macs.  Mac OS X & PS3 are different questions altogether :)
 
Hi All,

   anyone know what platform this pragma is aimed at, and whether we still really, really need it?  It is the source of the bulk of my warnings in the cog interpreter and I'd love to nuke it.

E.


Reply | Threaded
Open this post in threaded view
|

Re: #pragma export on/off

Igor Stasenko
In reply to this post by johnmci
 
2009/2/20 John M McIntosh <[hidden email]>:

>
> Well the pattern used  is like so where we ask the operating system to find
> the entry point secCanRenameImage in the SecurityPlugin
> which relies on the plugin either being external, or internal, and if the
> plugin actually has the secCanRenameImage.
> This code enables weak linking....
>
>                sCRIfn = ioLoadFunctionFrom("secCanRenameImage",
> "SecurityPlugin");
>                if (sCRIfn != 0) {
>                        okToRename =  ((sqInt (*)(void))sCRIfn)();
>                        if (!(okToRename)) {
>                                /* begin primitiveFail */
>                                foo->successFlag = 0;
>                                return null;
>                        }
>                }
>

Aha, i see.
The code like above insulting me, and if you remember my previous flow
of thoughts about it, i proposed to add a small API to VM, which lets
plugins/modules to publish symbols by themselves, without need in
relying on C linkage rules.

>
>
> On 19-Feb-09, at 7:52 PM, Igor Stasenko wrote:
>
>>
>> 2009/2/20 Eliot Miranda <[hidden email]>:
>>>
>>> Hi All,
>>>   anyone know what platform this pragma is aimed at, and whether we still
>>> really, really need it?  It is the source of the bulk of my warnings in the
>>> cog interpreter and I'd love to nuke it.
>>> E.
>>>
>> +1 for nuking it :)
>> As i understand this pragma ensuring that given symbol will appear in
>> module exports table, so other modules could lookup this symbol and
>> call these functions directly.
>> I fail see how such functions could be called directly bypassing rules
>> which ensuring a level of safety for VM - like InterpreterProxy.
>>
>>
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>
> --
> ===========================================================================
> John M. McIntosh <[hidden email]>
> Corporate Smalltalk Consulting Ltd.  http://www.smalltalkconsulting.com
> ===========================================================================
>
>
>
>



--
Best regards,
Igor Stasenko AKA sig.
Reply | Threaded
Open this post in threaded view
|

Re: #pragma export on/off

Ian Piumarta
In reply to this post by johnmci
 
On Feb 19, 2009, at 7:49 PM, John M McIntosh wrote:

> I'm not sure how it applies today, various newer versions of gcc  
> 4.x cheerfully makes everything private unless told otherwise.
> But I'll let Ian reply since I'm sure it still is required on some  
> platforms.

AFAIK it's not useful for any flavour of Unix.

Cheers,
Ian