[Vm-dev] another GCC issue?

[Eliot Miranda]

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20120328/07275f7d/attachment.htm