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 eliot.miranda@gmail.com wrote:
Hi Igor,
On Wed, Mar 28, 2012 at 5:43 AM, Igor Stasenko siguctua@gmail.com 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