[plt-scheme] Can't compile 372 on PPC64

On Thu, Mar 13, 2008 at 11:31 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
> At Thu, 13 Mar 2008 23:09:32 +0000, "Paulo J. Matos" wrote:
>  > On Wed, Mar 12, 2008 at 9:37 PM, Matthew Flatt <mflatt at cs.utah.edu> wrote:
>  > > At Wed, 12 Mar 2008 21:29:20 +0000, "Paulo J. Matos" wrote:
>  > >  > I've just tried to build PLT Scheme 372 on my PS3, PPC64 and got the
>  > >  > following error:
>  > >  >
>  > >  > cd gc2; make gen-deps
>  > >  > make[4]: Entering directory `/home/pmatos/plt-372/src/mred/gc2'
>  > >  > ../../mzscheme/mzscheme3m -qr "./gen-deps.ss"
>  > >  > Seg fault (internal error) at 0x40000030000
>  > >  > make[4]: *** [gen-deps] Aborted
>  > >  >
>  > >  > I was expecting it to work. Is there any architecture dependent code
>  > >  > that doesnt support ppc64?
>  > >
>  > >  My guess is that something is wrong with the 3m write-barrier signal
>  > >  handler, but that's just a guess.
>  > >
>  > >  Can you get a stack trace? I expect that just starting mzscheme3m will
>  > >  crash.
>  > >
>  >
>  > Here's the trace:
>  > Program received signal SIGSEGV, Segmentation fault.
>  > symbol_bucket (table=0x400002c6c58, key=0x40000000008 "",
>  > length=33685760, naya=0x40000000000)
>  >     at xsrc/symbol.c:39
>  > 39            int c = key [i ++ ] ;
>  > (gdb) bt
>
>  This signal is expected. It's to trigger the write barrier.
>
>  Please try
>
>   (gdb) handle SIGSEGV nostop noprint
>   (gdb) c
>
>  and it should eventually stop again in abort(). It may stop right away,
>  in which case the signal handler isn't working right. But it may stop
>  later.
>

(gdb) handle SIGSEGV nostop noprint
Signal        Stop      Print   Pass to program Description
SIGSEGV       No        No      Yes             Segmentation fault
(gdb) c
Continuing.
Seg fault (internal error) at 0x40000031000

Program received signal SIGABRT, Aborted.
0x0000040000182d64 in .raise () from /lib/libc.so.6
(gdb) bt
#0  0x0000040000182d64 in .raise () from /lib/libc.so.6
#1  0x0000040000184954 in .abort () from /lib/libc.so.6
#2  0x000000001016fcb0 in fault_handler (sn=<value optimized out>,
si=<value optimized out>,
    ctx=<value optimized out>) at ./sighand.c:20
#3  <signal handler called>
#4  symbol_bucket (table=0x400002c6c58, key=0x40000000008 "", length=33685760,
    naya=0x40000000000) at xsrc/symbol.c:39
#5  0x0000000010131c2c in symbol_bucket (table=<value optimized out>,
    key=<value optimized out>, length=14, naya=0x400002d0fbc) at
xsrc/symbol.c:111
#6  0x0000000010131e24 in scheme_intern_exact_symbol_in_table
(symbol_table=0x400002c6c58,
    kind=0, name=0x10194630 "#%module-begin", len=14) at xsrc/symbol.c:265
#7  0x00000000101323ac in scheme_intern_symbol (name=0x10194630
"#%module-begin")
    at xsrc/symbol.c:373
#8  0x000000001008bd90 in scheme_init_module (env=0x400002c6b14) at
xsrc/module.c:180
#9  0x0000000010028844 in scheme_basic_env () at xsrc/env.c:246
#10 0x000000001001b728 in actual_main (argc=<value optimized out>,
argv=0xfffff94f108)
    at xsrc/main.c:2104
#11 0x0000000010076874 in scheme_image_main (argc=<value optimized out>,
    argv=<value optimized out>) at xsrc/image.c:9
#12 0x000000001001d488 in main (argc=1, argv=<value optimized out>) at
xsrc/main.c:2226

>
>  > >  By poking at plt/src/mzscheme/gc2/newgc.c, can you confirm that
>  > >  SIXTY_FOUR_BIT_INTEGERS is correctly #defined (should be automatic), so
>  > >  that the GC knows that it's working in 64-bit mode?
>  > >
>  >

Yes, you're right... It is being compiled with SIXTY_FOUR....

mzschemecgc works fine though, although you have probably guessed that by now.

Do you think it's worth a try the current SVN head?

>  > newgc.c comes during the compulation of gc2.c:
>  > gcc -g -O2 -DNEWGC_BTC_ACCOUNT  -I./.. -I./../include  -Wall  -c
>  > ./gc2.c -o gc2.o
>  > In file included from ./gc2.c:15:
>  > ./newgc.c: In function 'pop_ptr':
>  > ./newgc.c:1349: warning: dereferencing type-punned pointer will break
>  > strict-aliasing rules
>  >
>  > Nothing shows that SIXTY_FOUR_BIT_INTEGERS is defined during compilation.
>
>  Nothing would be particularly visible during compilation, but if you
>  add something like
>
>   #ifdef SIXTY_FOUR_BIT_INTEGERS
>   this is an error
>   #endif
>
>  to the end of the file, it should fail to compile.
>
>  Thanks,
>  Matthew
>
>
>
>



-- 
Paulo Jorge Matos - pocm at soton.ac.uk
http://www.personal.soton.ac.uk/pocm
PhD Student @ ECS
University of Southampton, UK
Sponsor ECS runners - Action against Hunger:
http://www.justgiving.com/ecsrunslikethewind