Porting sbcl to DragonFly

[vasily postnicov]

> Actually, there have been at least two other attempts to support SBCL.
> Mine (http://leaf.dragonflybsd.org/~marino/ see sbcl.tar.bz2
> 23-dec-2011) and profmakx (I think it was him).  I believe he was
> actually successful, but the patches were never imported into pkgsrc.  I
> don't remember the exact details.  If this is true, then the logic
> starting point is those patches although they are for an older release now.

> The long term solution is to get your/these patches into the upstream
> codebase so no patches are required.

> 1. use pthread
> 2. TLS is present on DragonFly.  It's the reason version 2.0 was
> released inside of version 1.14 (I think).  Anyway, DragonFly has had
> TLS for many years now.
> 3. I think the only think you do with a x86-64 machine with regards to
> i386 is to set up a bootloader and install DragonFly twice on it (32 and
> 64 bit versions).  It is still not possible to run 32-bit binaries on
> i386 on DragonFly, and I doubt it will ever be possible.

> So thanks on the initiative and I really think the next step is to hear
> from profmakx (TBC) because I was under the impression all the issues
> were solved.  Obviously my attempt didn't get all the way.

> John

------------------------------
> (http://leaf.dragonflybsd.org/~marino/ see sbcl.tar.bz)

Interesting, thanks. But has it threads and FPU exceptions handler on
x86-64? (Handlers can be installed by defining X86_64_SIGFPE_FIXUP like it
is done in FreeBSD code). You can check it by evaluating (/ 6.0 0.0). If
you can see 'division-by-zero condition in debugger, it is installed.

> and profmakx (I think it was him)

All I can find is http://leaf.dragonflybsd.org/~profmakx/sbcl/crash/
There is lib/ directory in archive, which contains nothing of interest.

I am still concerned about sb-concurrency's symbol-value-in-thread.3 test .
It always causes sbcl to crash and always in different fashion (sometimes
it just prints "Illegal instruction" and crashes, sometimes sbcl debugger
is invoked with "The integrity of this image is possibly compromised"
message and sometimes there are "[diagnostic] cache_lock: blocked on
0xffffffe00653eac8 sbcl.core" kernel messages). Definitely, something is
wrong with multithreading, but real tasks (like hunchentoot) work well.

By the way, there is implementation of :sb-futex feature in sbcl for
FreeBSD (but it is not enabled by default). It uses umtx_wait and umtx_wake
functions for implementation of mutexes. As I understand it, DFBSD
analogues are umtx_sleep and umtx_wakeup.

SBCL checks if return code of umtx_wait is 0, ETIMEDOUT, EINTR or any other
value (see src/runtime/bsd-os.c, src/code/target-thread.lisp).

According to man umtx in DragonFly, umtx_sleep returns 0 or -1 and sets
errno to EBUSY, EWOULDBLOCK, EINTR, EINVAL.

So what is ETIMEDOUT and why umtx_sleep does not return it?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20130330/4f4eefc7/attachment-0002.html>