[Vm-dev] About Cog on linux

Eliot Miranda eliot.miranda at gmail.com
Fri Feb 11 00:12:18 UTC 2011


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

>
> On 10 February 2011 19:38, Eliot Miranda <eliot.miranda at gmail.com> wrote:
> >
> >
> >
> > 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.
>
> i can do that , but on two different architectures.
>

I mean of course two different compilations on the same architecture of the
same source, one that crashes and one that doesn't.



> On linux it crashing , no matter what i do (as you can see even stack
> based are crashing).
>

Sometimes my linux builds work and sometimes they don't, and I see no rhyme
or reason why.  Thats what we're trying to work out.  So we need to look at
linux, and compare builds that work against those that don't.  So the first
requirement is to obtain reproducible builds that work and that don't.


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


More information about the Vm-dev mailing list