[racket-dev] Compile racket without native compare-and-swap support?

From: Matthew Flatt (mflatt at cs.utah.edu)
Date: Thu Jul 3 04:07:46 EDT 2014

I've just built Racket for Linux on MIPS without problem, so I don't
think it's a misaligned access.

I tried Linux because I found QEMU images that made it relatively
convenient to try:

  http://people.debian.org/~aurel32/qemu/mipsel/

If you can point me to similar images for OpenBSD, I'd be happy to take
a closer look.

At Wed, 18 Jun 2014 04:33:46 +0200, Juan Francisco Cantero Hurtado wrote:
> Sorry for revive an old thread but recently an OpenBSD developer 
> (jturner) has been testing racket on mips64el (loonsong).
> 
> He sees a SIGBUS at the same point. GDB doesn't show a backtrace.
> 
> Maybe the interpreter is performing a misaligned access to the memory at 
> some point and the problem is not only related to the growing direction 
> of the stack. It can even hurt slightly the performance on other platforms.
> 
> HPPA and MIPS64 only permit aligned access to memory, however amd64, arm 
> (almost always) and x86 doesn't have this problem.
> 
> On 04/30/14 15:49, Juan Francisco Cantero Hurtado wrote:
> > On 04/30/14 02:07, Matthew Flatt wrote:
> >> It's been a very long time since I touched a machine where the stack
> >> grows up. Does changing `c->cont->buf.stack_size` to `c->stack_size`
> >> work?
> >
> > I'm not sure:
> >
> > mkdir xsrc
> > make xsrc/precomp.h
> > env XFORM_PRECOMP=yes ../racketcgc  -cqu
> > /usr/ports/pobj/racket-6.0-debug/racket-6.0/src/racket/gc2/xform.rkt
> > --setup . --cpp "cc -E -I./..
> > -I/usr/ports/pobj/racket-6.0-debug/racket-6.0/src/racket/gc2/../include
> > -I/usr/local/include -I/usr/X11R6/include -pthread -I/usr/local/include
> >     -DMZ_USES_SHARED_LIB "  --keep-lines -o xsrc/precomp.h
> > /usr/ports/pobj/racket-6.0-debug/racket-6.0/src/racket/gc2/precomp.c
> > Segmentation fault (core dumped)
> >
> > The output of gdb:
> > http://juanfra.info/bl/racket-2014/backtrace-racket-6.0.log
> >
> >>
> >> At Wed, 30 Apr 2014 00:21:10 +0200, Juan Francisco Cantero Hurtado wrote:
> >>> On 04/28/14 21:13, Matthew Flatt wrote:
> >>>> Sorry --- I now see that `--enable-pthread` is forced for OpenBSD. I
> >>>> think it should be on by default, but not actually forced, so I've made
> >>>> that repair.
> >>>>
> >>>> More to the point, I've pushed a repair so that CAS is attempted only
> >>>> when futures or places are enabled.
> >>>
> >>> I've compiled racket 6.0 with both patches. Now I see another
> >>> (unrelated) problem:
> >>>
> >>> setjmpup.c: In function 'scheme_uncopy_stack'
> >>> setjmpup.c:358: error: 'struct Scheme_Cont' has no member named 'buf'
> >>>
> >>> http://juanfra.info/bl/racket-2014/racket-6.0-3.log
> >>>
> >>>>
> >>>> At Mon, 28 Apr 2014 20:45:35 +0200, Juan Francisco Cantero Hurtado
> >>>> wrote:
> >>>>> On 04/28/14 20:08, Matthew Flatt wrote:
> >>>>>> I think `--enable-pthread` is triggering the attempt to use CAS. Can
> >>>>>> you leave that one out?
> >>>>>
> >>>>> I tried without enable-pthread. I see the same problem
> >>>>> http://juanfra.info/bl/racket-2014/racket-6.0-2.log
> >>>>>
> >>>>>>
> >>>>>> At Mon, 28 Apr 2014 19:59:10 +0200, Juan Francisco Cantero Hurtado
> >>>>>> wrote:
> >>>>>>> On 04/28/14 01:03, Matthew Flatt wrote:
> >>>>>>>> At Mon, 28 Apr 2014 00:58:48 +0200, Juan Francisco Cantero
> >>>>>>>> Hurtado wrote:
> >>>>>>>>> I'm trying to compile Racket 6.0 on OpenBSD/hppa but the
> >>>>>>>>> compilation
> >>>>>>>>> fails because there is not support for CAS on OpenBSD/hppa. Is it
> >>>>>>>>> possible compile racket on platforms without atomic CAS?.
> >>>>>>>>
> >>>>>>>> Does it help to use
> >>>>>>>>
> >>>>>>>>      --disable-places --disable-futures
> >>>>>>>>
> >>>>>>>> as arguments to `configure`?
> >>>>>>>
> >>>>>>> No, I use always both arguments because we don't have support for
> >>>>>>> tls on
> >>>>>>> OpenBSD. Here is the log of the build:
> >>>>>>> http://juanfra.info/bl/racket-2014/racket-6.0.log
> 
> 
> _________________________
>   Racket Developers list:
>   http://lists.racket-lang.org/dev

Posted on the dev mailing list.