Smalltalk › Squeak › Squeak VM

#pragma export on/off

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

9 messages Options

Eliot Miranda-2

#pragma export on/off

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.

Brad Fowlow-2

Re: #pragma export on/off

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.

johnmci

Re: #pragma export on/off

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
=
=
=
========================================================================

Igor Stasenko

Re: #pragma export on/off

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.

johnmci

Re: #pragma export on/off

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
=
=
=
========================================================================

Eliot Miranda-2

Re: #pragma export on/off

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
===========================================================================

Eliot Miranda-2

Re: #pragma export on/off

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.

Igor Stasenko

Re: #pragma export on/off

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.

Ian Piumarta

Re: #pragma export on/off

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