[Vm-dev] another GCC issue?
eliot.miranda at gmail.com
Wed Mar 28 15:55:39 UTC 2012
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
^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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev