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 _________________________ Racket Developers list: http://lists.racket-lang.org/dev