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

From: Juan Francisco Cantero Hurtado (iam at juanfra.info)
Date: Tue Jun 17 22:33:46 EDT 2014

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



Posted on the dev mailing list.