[Vm-dev] About Cog on linux

Eliot Miranda eliot.miranda at gmail.com
Thu Feb 10 18:38:14 UTC 2011


On Thu, Feb 10, 2011 at 9:55 AM, Igor Stasenko <siguctua at gmail.com> wrote:

>
> On 10 February 2011 18:34, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >
> > Hi Igor,
> >
> > On Thu, Feb 10, 2011 at 1:03 AM, Igor Stasenko <siguctua at gmail.com>
> wrote:
> >>
> >> On 9 February 2011 20:04, Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
> >> >
> >> >
> >> > That's essentially what I see but the variability isn't between cmake
> and configure but between different runs of configure.  For example, you'll
> see that I released 2259 (SimpleStackBasedCogit) and 2361
> (StackToRegisterMappingCogit) at the weekend.  That's because 2360 which had
> -O2 for gcc3x-cointerp.c crashed on startup on my test case
> (Squeak4.2-10856-beta.image) in one of the early performs as classes are
> sent startUp: on startup.  So I lowered optimization, checked-in 2361,
> built, checked it didn't crash and released.  However, now I try and rebuild
> exactly the same sources but using -O2 for gcc3x-cointerp.c I can't get it
> to crash.  This is exactly analogous to a few weeks back when I was
> convinced that the optimization level of the heartbeat caused it to crash if
> at -O2.  When Andreas asked me to reproduce on the internal Teleplace build
> I couldn't get it to repeat.  So something is very odd indeed, sensitive
> perhaps to the timestamp in the executable or some such.  However, now at
> least I know what I'm looking for and the next tie I build somethign that
> crashes on the test case I will attempt to debug.
> >> >
> >> >
> >>
> >> I tried today with debug info enabled (all source files are compiled
> with:
> >>
> >> compilerFlags
> >>
> >>        ^ '-g3 -O1 -msse2 -D_GNU_SOURCE -DDEBUG -DITIMER_HEARTBEAT=1
> >>        -DNO_VM_PROFILE=1 -DCOGMTVM=0 -DDEBUGVM=1'
> >>
> >> )
> >>
> >
> > please change that to include -save-temps.  We can then see what the
> generated assembly and object files are and that will really help analyse.
>  Also, can you somehow freeze this source so that we can repeat the
> compilation exactly?  i.e. avoid generating a different version.c with a
> different date in it.  We must try and repeat the compilation exactly with
> no temporal or path-derived artifacts.
> >
> >\
>
> ok i made such config:
>
> ....results/Cog -version
> 3.9-7 #1 <HERE IS SUPPOSED TO BE THE DATE> <HERE IS SUPPOSED TO BE gcc
> VERSION>
> Croquet Closure Stack VM [StackInterpreter
> VMMaker-oscog-IgorStasenko.Stasenko.49]
> <FAKE FROZEN VERSION FOR DEBUGGING PURPOSES>
> plugin path: /home/sig/vmbuild/build/results/ [default:
> /home/sig/vmbuild/build/results/]
>
>
> it also produces a lot of .i and .s files around build dir..
>

Right.  That's what -save-temps does.  And that's useful data, especially in
seeing what code gcc produces for different -O levels.


>
> You can try building it by loading CMakeVMMaker-IgorStasenko.27
> package and doing:
>
> FixedVerSIDebugUnixConfig generateWithSources
>
> or tell me what to do next :)
>

You need to try and produce one build that crashes and one build that
doesn't (based e.g. on -O level).  When you have that compare the two up to
the point of failure.


> --
> Best regards,
> Igor Stasenko AKA sig.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20110210/4f20acc9/attachment.htm


More information about the Vm-dev mailing list