Strange error while building stack vm

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

Re: Strange error while building stack vm

Igor Stasenko

On 30 December 2010 22:35, Eliot Miranda <[hidden email]> wrote:

>
> Hi Igor,
>
> On Thu, Dec 30, 2010 at 1:37 AM, Igor Stasenko <[hidden email]> wrote:
>>
>> (warnings are supressed)
>>
>> In file included from
>> /Users/sig/projects/cog/sig-cog/build/../platforms/Mac
>> OS/vm/Developer/sqGnu.h:46,
>>                 from /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:20:
>> /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c: At top level:
>> /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c: At top level:
>> /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:15490: note:
>> ‘theIP’ was declared here
>> /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:34730: note:
>> ‘hdrTypeBits’ was declared here
>> /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:14690: note:
>> ‘hdrTypeBits’ was declared here
>> /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:35424: note:
>> ‘freeChunkSize’ was declared here
>> /Users/sig/projects/cog/sig-cog/src/vm/gcc3x-interp.c:35311: note:
>> ‘freeChunkSize’ was declared here
>> /var/folders/kE/kEXZB7BWHXWwxswd6aL4XU+++TM/-Tmp-//ccIxqx9C.s:143250:FATAL:Symbol
>> L0bereaveAllMarriedContexts already defined.
>
> So two things here.  One is what these labels are.  The labels that are added by the code generator simply for performance measurement.  See the define of VM_LABEL in the various sqPlatformSpecific.h files.  So this is not necessary but essential if using the VMProfiler to profile the stack interpreter.  If a method is marked with an <asmLabel: true> pragma the code generator outputs a label for it and one can ten identify the particular code sequence (e.g. a bytecode) in the VMProfiler.
> The other is what causes the error.  The C compiler can choose to inline code, but both gcc and icc appear not to examine the code they're inlining for inserted labels and end up duplicating the labels inserted by VM_LABEL.  Since this duplication depends on the exact source and compiler optimization level in force there's no easy way to predict when a label will be duplicated.  The fix is to add <asmLabel: false> to the relevant method.  A better fix might be to add a <C: #noinline> pragma that would result in turning off inlining for the relevant function (for example I don't think it appropriate at all that the C compiler is inlining bereaveAllMarriedContexts; it doesn't happen all that often - basically at snapshot or voiding machien code - and inlining it is a silly decision on the C compiler's part).  A hack fix is of course to simply define VM_LABEL as 0, but that criples the VMProfiler.

Thanks for explanation and a hint. But as you can see this is a code
generator, which inlining this function,
and then for duplicating label, C compiler inlining
voidVMStateForSnapshot() at least twice.
Yes, since this code is not critical for VM performance, we could
either disable inlining or remove label.

Because my first reaction was disable labels ...

I guess this happens because it compiles it with whole module
optimization flag: -O3 ,
which i took from xcode project 'Release' config.


> HTH
> Eliot
>>
>>
>> i found the only use of it in generated code:
>>
>> voidVMStateForSnapshot(void) {
>> DECL_MAYBE_SQ_GLOBAL_STRUCT
>>    sqInt activeContext;
>>    sqInt header;
>>    sqInt oop;
>>    sqInt sz;
>>
>>        activeContext = divorceAllFrames();
>>        /* begin bereaveAllMarriedContexts */
>>        VM_LABEL(0bereaveAllMarriedContexts);
>>
>>
>> but gcc insists that there are another one???
>>
>> --
>> Best regards,
>> Igor Stasenko AKA sig.
>
>
>



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

Re: Strange error while building stack vm

Bert Freudenberg
In reply to this post by johnmci


On 30.12.2010, at 17:16, John M McIntosh wrote:

>
>
> On 2010-12-30, at 5:02 AM, Colin Putney wrote:
>
>>> In fact you should know that any vm built with the Mac OS tree and
>>> submitted to the osx app store will be rejected by apple
>>
>> So? The Mac app store doesn't exist yet, and Cog isn't production
>> ready anyway. For now, folks are just trying to get a working Cog VM
>> for their own use. We'll worry about Apple's policies when the time
>> comes.
>>
>> Colin
>
> Jan 6th 2011, 7 days from now and Apple's going to run right over anyone in the way...
> Warranty on the squeak 4.x series VM is null and void that morning...

Huh? That sounds unwarrantedly bitter.

Nothing is going to stop working on Jan 6th. People will just have an additional way to install software. I don't see a problem. (Yet, anyway)

- Bert -


12