[Vm-dev] another GCC issue?
siguctua at gmail.com
Wed Mar 28 17:20:28 UTC 2012
Thanks for suggestion.. i did following:
<var: #address type: #'void *'>
^self cCode: '(unsigned long)(address) >= (unsigned
long)&abstractOpcodes && (unsigned long)address < (unsigned
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;"
>> 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 && address < (void *)&abstractOpcodes[opcodeIndex]'
> we use
> ^self cCode: '(unsigned long)(address) >= (unsigned long)&abstractOpcodes && address < (unsigned long)&abstractOpcodes[opcodeIndex]'
>> 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
>> Ah.. yes.. and addition info.. the difference between generateForDebug
>> and generateForRelease
>> Best regards,
>> Igor Stasenko.
More information about the Vm-dev