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 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. |
Hi Igor, On Wed, Mar 28, 2012 at 5:43 AM, Igor Stasenko <[hidden email]> wrote:
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 () best, Eliot |
Thanks for suggestion.. i did following: addressIsInInstructions: address <var: #address type: #'void *'> ^self cCode: '(unsigned long)(address) >= (unsigned long)&abstractOpcodes[0] && (unsigned long)address < (unsigned long)&abstractOpcodes[opcodeIndex]' inSmalltalk: [(abstractOpcodes object identityIndexOf: address) between: 1 and: opcodeIndex] but it doesn't helps. Still got crash :( Perhaps config should watch out for optimization flags for cogit.c, since we know there is an issues with it. On 28 March 2012 17:55, Eliot Miranda <[hidden email]> wrote: > > 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 > > -- Best regards, Igor Stasenko. |
ok i found why: i was using llvm compiler, not vanilla gcc. but we should make it work on llvm eventually, 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. |
Or we can do like this: http://staticimport.blogspot.fr/2012/02/building-gcc-462-on-os-x-lion.html -- Best regards, Igor Stasenko. |
In reply to this post by Igor Stasenko
On Tue, Apr 3, 2012 at 8:29 AM, Igor Stasenko <[hidden email]> wrote:
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 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
|
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. |
Indeed! Stef On Apr 3, 2012, at 7:05 PM, Igor Stasenko wrote: > > 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. |
Free forum by Nabble | Edit this page |