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

On 07/03/14 10:07, Matthew Flatt wrote:
> I've just built Racket for Linux on MIPS without problem, so I don't
> think it's a misaligned access.

Thanks for take a look to the problem :)

Be aware linux has code in the kernel to fix misaligned access to 
memory. You can disable this behaviour in mips64 following this guide 
http://www.linux-mips.org/wiki/Alignment (or arm 
https://www.kernel.org/doc/Documentation/arm/mem_alignment).

Maybe the problem is in some of the code inside of some C macro related 
to OpenBSD.

>
> I tried Linux because I found QEMU images that made it relatively
> convenient to try:
>
>    http://people.debian.org/~aurel32/qemu/mipsel/

I've compiled racket in qemu with that image and with the workarounds 
mentioned above disabled. Racket builds without problem. The same with 
linux/armv7.

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

I've been trying during the last days to run OpenBSD mips64/mips64el 
with qemu but I failed. I will try with other architectures.


>
> 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