[Vm-dev] another GCC issue?

[Igor Stasenko]

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



-- 
Best regards,
Igor Stasenko.