another GCC issue?

>
> Hi Igor,
>
> On Wed, Mar 28, 2012 at 5:43 AM, Igor Stasenko <[hidden email]> wrote:
>>
>>
>> or perhaps not..
>> i am trying to build the cog cocoa VMs using configs made by Esteban..
>>
>> CogCocoaIOSConfig new
>> "       generateForDebug;"
>>        generateForRelease;
>>        addExternalPlugins: #( FT2Plugin  );
>>        addInternalPlugins: #( UnixOSProcessPlugin );
>>        generateSources; generate.
>>
>>
>> it is not a functional bug.. because if i use #generateForDebug,
>> everything works fine (but slow ;)
>> but if i do #genearateForRelease, VM crashes with following:
>>
>> Program received signal EXC_BAD_ACCESS, Could not access memory.
>> Reason: KERN_INVALID_ADDRESS at address: 0x5eedca7a
>
>
>  0x5eedca7a = 5EEDCA5E + a little, one orf my bad hex puns.  This is early in initialization in Cogit>compileClosedPICPrototype.  5EEDCA5E  is used as a branch target in the PIC prototype.  The concretize methods need to know whether a jump target is pointing to a fixup or is some real address to jump to.  Look at the code generated for Cogit>addressIsInInstructions: in the various concretize methods for jumps.  Looks like the optimizer is decidging that addressIsInInstructions: is always true.
>
> e.g. what if you redefine Cogit>addressIsInInstructions: so that instead of
> ^self cCode: 'address >= (void *)&abstractOpcodes[0] && address < (void *)&abstractOpcodes[opcodeIndex]'
> we use
> ^self cCode: '(unsigned long)(address) >= (unsigned long)&abstractOpcodes[0] && address < (unsigned long)&abstractOpcodes[opcodeIndex]'
>
> ?
>
> HTH
> Eliot
>
>> 0x0000dfb6 in concretizeAt ()
>> (gdb) bt
>> #0  0x0000dfb6 in concretizeAt ()
>> #1  0x00014996 in generateInstructionsAt ()
>> #2  0x000000c9 in ?? ()
>>
>> i am not sure how to squeeze more info about this crash point..
>> because stack trace is cut by gdb,
>> which /.another rant here./ stupidly stops scanning stack frames once
>> it discovers a frame which code is outside of memory covered by debug
>> information..
>>
>> Ah.. yes.. and addition info.. the difference between generateForDebug
>> and generateForRelease
>>
>> compilerFlagsRelease
>>        ^#(
>>        "'-fobjc-direct-dispatch'"
>>        '-msse3'
>>        "'-msse4.1'"
>>        "'-msse4.2'"
>>        "'-mdynamic-no-pic'"
>>        "'-fwritable-strings'"
>>        '-Os'
>>        '-fvisibility=hidden'
>>        '-funroll-loops'
>>        "'-fno-asm'"
>>        '-fasm-blocks'
>>        '-finline-functions'
>>        '-mfpmath=sse'
>>        '-fomit-frame-pointer'
>>        '-march=pentium-m'
>>        '-mtune=prescott'
>>        '-falign-functions=16'
>>        '-fno-gcse'
>>        '-fno-cse-follow-jumps'
>>        '-std=gnu99'
>>        '-DBUILD_FOR_OSX'
>>        '-DUSE_INLINE_MEMORY_ACCESSORS'
>>        '-DLSB_FIRST'
>>        '-DUSE_INLINE_MEMORY_ACCESSORS'
>>        '-DHAVE_SYS_TIME_H'
>>        '-DHAVE_NANOSLEEP'
>>        '-DICC_DEBUG=0'
>>        '-DICC_OPTLEVEL="speedHLO"'
>>        '-DICC_OPT_IPO_FOR_SINGLE_FILE_COMPILATION=1'
>>        '-DICC_OPT_PARALLEL=0'
>>        '-DICC_OPT_PREFETCH_INSERTION=1'
>>        '-DICC_OPT_PROVIDE_FRAME_PTR=0'
>>        '-DICC_OPT_USE_ARCH_IA32="SSE42"')
>>
>>
>> compilerFlagsDebug
>>        ^#(
>>           '-g3'
>>           '-O0'
>>           '-DDEBUGVM=1')
>>
>> --
>> Best regards,
>> Igor Stasenko.
>
>
>
>
> --
> best,
> Eliot
>
>

>
> This existed pre-cog I did talk to apple's llvm folks who told me to figure out where the compiler creates the bad code.   Oh sure...  Perhaps you could take a pre cog/stack vm from 2 years back and confirm it's broken before smacking them with extras like alloca, code generation etc..
>
> Sent from my iPhone
>
> On Apr 3, 2012, at 12:24 PM, Eliot Miranda <[hidden email]> wrote:
>
>
>
> On Tue, Apr 3, 2012 at 8:29 AM, Igor Stasenko <[hidden email]> wrote:
>>
>>
>> ok i found why: i was using llvm compiler, not vanilla gcc.
>>
>> but we should make it work on llvm eventually,
>
>
> I agree, and I put some effort into this, managing to get something that starts up at -O1 (I think) but not at -O2 (or at -O0 but not at -O1).  I *think* this might be a bug in llvm, because the Cogit is pretty aggressive in its use of alloca.  I should try and make a report for the llvm maintainers.  Either I'll find out I've made a mistake or they'll fix the bug ;)  Biut finding the time is as always the issue :)
>
>
>>
>> since Apple seems to be
>> dropping support of old gcc compilers:
>>
>> http://stackoverflow.com/questions/8707367/using-gcc-not-llvm-gcc-with-mac-os-x-lion
>>
>> --
>> Best regards,
>> Igor Stasenko.
>
>
>
>
> --
> best,
> Eliot
>
>

>
> Well, i am a bit far from knowing why compiler fails to compile it or
> where.. my main problem in last 3 hours was to get gcc working.
>
> The problem is that Xcode 4.3 are not including GCC-4.2 by default..
> nor the "command-line tools" addon.
>
> I spent 2 hours installing/reinstalling the stuff and found the best
> way is to install it from here:
> https://github.com/kennethreitz/osx-gcc-installer
>
> Also, i was also forced to change the path to SDKs:
>
> sudo xcode-select -switch
> /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer
>
> then after
> export CC=/usr/bin/gcc-4.2
>
> cmake can build VM using right version of compiler...
>
> what a mess...
>
>
> On 3 April 2012 18:47, John M McIntosh <[hidden email]> wrote:
>>
>> This existed pre-cog I did talk to apple's llvm folks who told me to figure out where the compiler creates the bad code.   Oh sure...  Perhaps you could take a pre cog/stack vm from 2 years back and confirm it's broken before smacking them with extras like alloca, code generation etc..
>>
>> Sent from my iPhone
>>
>> On Apr 3, 2012, at 12:24 PM, Eliot Miranda <[hidden email]> wrote:
>>
>>
>>
>> On Tue, Apr 3, 2012 at 8:29 AM, Igor Stasenko <[hidden email]> wrote:
>>>
>>>
>>> ok i found why: i was using llvm compiler, not vanilla gcc.
>>>
>>> but we should make it work on llvm eventually,
>>
>>
>> I agree, and I put some effort into this, managing to get something that starts up at -O1 (I think) but not at -O2 (or at -O0 but not at -O1).  I *think* this might be a bug in llvm, because the Cogit is pretty aggressive in its use of alloca.  I should try and make a report for the llvm maintainers.  Either I'll find out I've made a mistake or they'll fix the bug ;)  Biut finding the time is as always the issue :)
>>
>>
>>>
>>> since Apple seems to be
>>> dropping support of old gcc compilers:
>>>
>>> http://stackoverflow.com/questions/8707367/using-gcc-not-llvm-gcc-with-mac-os-x-lion
>>>
>>> --
>>> Best regards,
>>> Igor Stasenko.
>>
>>
>>
>>
>> --
>> best,
>> Eliot
>>
>>
>
>
>
> --
> Best regards,
> Igor Stasenko.