DragonFly BSD
DragonFly users List (threaded) for 2013-03
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: Porting sbcl to DragonFly


From: vasily postnicov <shamaz.mazum@xxxxxxxxx>
Date: Sat, 30 Mar 2013 14:25:40 +0400

--20cf307f37f440125b04d921cfc9
Content-Type: text/plain; charset=ISO-8859-1

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

--20cf307f37f440125b04d921cfc9
Content-Type: text/html; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div class=3D"gmail_extra"><pre>&gt; Actually, there have =
been at least two other attempts to support SBCL.=20
&gt; Mine (<a href=3D"http://leaf.dragonflybsd.org/%7Emarino/";>http://leaf.=
dragonflybsd.org/~marino/</a> see sbcl.tar.bz2=20
&gt; 23-dec-2011) and profmakx (I think it was him).  I believe he was=20
&gt; actually successful, but the patches were never imported into pkgsrc. =
 I=20
&gt; don&#39;t remember the exact details.  If this is true, then the logic=
=20
&gt; starting point is those patches although they are for an older release=
 now.

&gt; The long term solution is to get your/these patches into the upstream=
=20
&gt; codebase so no patches are required.

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

&gt; So thanks on the initiative and I really think the next step is to hea=
r=20
&gt; from profmakx (TBC) because I was under the impression all the issues=
=20
&gt; were solved.  Obviously my attempt didn&#39;t get all the way.

&gt; John
</pre>


    <hr>&gt; (<a href=3D"http://leaf.dragonflybsd.org/%7Emarino/";>http://le=
af.dragonflybsd.org/~marino/</a> see <a href=3D"http://sbcl.tar.bz";>sbcl.ta=
r.bz</a>)<br><br></div><div class=3D"gmail_extra">Interesting, thanks. But =
has it threads and FPU exceptions handler on x86-64? (Handlers can be insta=
lled 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 &#39;division-by-zer=
o condition in debugger, it is installed.<br>
<br>&gt; and profmakx (I think it was him)<br><br></div><div class=3D"gmail=
_extra">All I can find is <a href=3D"http://leaf.dragonflybsd.org/~profmakx=
/sbcl/crash/">http://leaf.dragonflybsd.org/~profmakx/sbcl/crash/</a><br></d=
iv>
<div class=3D"gmail_extra">There is lib/ directory in archive, which contai=
ns nothing of interest.<br></div><div class=3D"gmail_extra"><br></div><div =
class=3D"gmail_extra">I am still concerned about sb-concurrency&#39;s symbo=
l-value-in-thread.3 test . It always causes sbcl to crash and always in dif=
ferent fashion (sometimes it just prints &quot;Illegal instruction&quot; an=
d crashes, sometimes sbcl debugger is invoked with &quot;The integrity of t=
his image is possibly compromised&quot; message and sometimes there are &qu=
ot;[diagnostic] cache_lock: blocked on 0xffffffe00653eac8 sbcl.core&quot; k=
ernel messages). Definitely, something is wrong with multithreading, but re=
al tasks (like hunchentoot) work well.<br>
<br></div><div class=3D"gmail_extra">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.<br>
<br></div><div class=3D"gmail_extra">SBCL checks if return code of umtx_wai=
t is 0, ETIMEDOUT, EINTR or any other value (see src/runtime/bsd-os.c, src/=
code/target-thread.lisp).<br><br></div><div class=3D"gmail_extra">According=
 to man umtx in DragonFly, umtx_sleep returns 0 or -1 and sets errno to EBU=
SY, EWOULDBLOCK, EINTR, EINVAL.<br>
<br></div><div class=3D"gmail_extra">So what is ETIMEDOUT and why umtx_slee=
p does not return it?<br> </div></div>

--20cf307f37f440125b04d921cfc9--



[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]