<div dir="ltr"><div><div><div><br><div class="gmail_extra"><br><br><div class="gmail_quote">2013/3/30 Chris Turner <span dir="ltr"><<a href="mailto:c.turner@199technologies.com" target="_blank">c.turner@199technologies.com</a>></span><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div class="im">On 03/30/13 00:16, vasily postnicov wrote:<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
So I have some questions:<br>
1. src/runtime/Config.x86-64-<u></u>freebsd states that we must use 1:1 threading not m:n threading and uses lthr for that purpose. It seems that there isn't lthr in dragonfly, only lpthread is present. Should I use it? Is 1:1 threading supported? (It seems to work with lpthread anyway).<br>
2. SBCL uses GCC TLS with (and only with) FreeBSD. I heard something about lack of "native" TLS in FreeBSD. Is it true? Is TLS present on DragonFly?<br>
</blockquote>
<br></div>
I'm pretty certain that both of these are out of date statements w/r/t FreeBSD (relating to libc_r and KSE in the 4,5,6,7 era)<br>
<br>
To also clarify, our libpthread uses 1:1 model.<br>
<br>
If you get frustrated or finished with SBCL and want some other 'Low Hanging LISP Fruit',<br>
fixing up boehmgc should make ECL work properly, and will also help with other fun and interesting<br>
interpreters - see also:<br>
<br>
<a href="http://bugs.dragonflybsd.org/issues/1525" target="_blank">http://bugs.dragonflybsd.org/<u></u>issues/1525</a><br>
<br>
ECL is a bit more straightforward of a LISP since it isn't doing as<br>
much code generation/low level stuff IIRC, instead relying on more 'standard' posixy stuff.<br>
<br>
Cheers and good luck!<span class=""><font color="#888888"><br>
<br>
- Chris<br>
</font></span></blockquote></div><br></div><div class="gmail_extra">Thanks for helping. I still have problems with sb-concurrency on x86-64. I've also implemented x86 support (but without threads) just because it is simple "make sbcl to do like in FreeBSD" job. Thread support is rather difficult for me to implement. To be specific, look at this piece of code:<br>
<br>int arch_os_thread_init(struct thread *thread) {<br><br>#ifdef LISP_FEATURE_SB_THREAD<br> int n;<br><br> struct segment_descriptor ldt_entry = { 0, 0, SDT_MEMRW, SEL_UPL, 1,<br> 0, 0, 1, 0, 0 };<br>
<br> set_data_desc_addr(&ldt_entry, thread);<br> set_data_desc_size(&ldt_entry, dynamic_values_bytes);<br><br> n = i386_set_ldt(LDT_AUTO_ALLOC, (union descriptor*) &ldt_entry, 1);<br> if (n < 0) {<br>
perror("i386_set_ldt");<br> lose("unexpected i386_set_ldt(..) failure\n");<br> }<br> FSHOW_SIGNAL((stderr, "/ TLS: Allocated LDT %x\n", n));<br> thread->tls_cookie=n;<br>
arch_os_load_ldt(thread);<br><br></div><div class="gmail_extra">....... /* Skipped few lines */<br></div><div class="gmail_extra">}<br><br>int arch_os_thread_cleanup(struct thread *thread) {<br><br>#if defined(LISP_FEATURE_SB_THREAD)<br>
int n = thread->tls_cookie;<br><br> /* Set the %%fs register back to 0 and free the ldt by setting it<br> * to NULL.<br> */<br> FSHOW_SIGNAL((stderr, "/ TLS: Freeing LDT %x\n", n));<br><br> __asm__ __volatile__ ("mov %0, %%fs" : : "r"(0));<br>
i386_set_ldt(n, NULL, 1);<br>#endif<br><br> return 1; /* success */<br>}<br><br></div><div class="gmail_extra">The problem is in i386_set_ldt. LDT_AUTO_ALLOC as a first argument says to this FreeBSD version of i386_set_ldt to add new segment descriptor to LDT and return its selector. In DragonFly, first argument is itself a selector number and there is no such thing LDT_AUTO_ALLOC, so I have completely no idea what I must do here.<br>
<br></div><div class="gmail_extra">BTW, arch_os_thread_init, of course, is called from new thread, not from parent thread. <br><br></div><div class="gmail_extra">Also, I wonder why LDT is used at all. Wikipedia says, that descriptor tables were used in i286 as a memory addressing mechanism prior to paging (AFAIK, paging first appeared in i386). With descriptor tables it was possible to translate "logical" addresses to real physical addresses (sorry, if I use wrong terminology). With LDT it was possible to translate same "logical" addresses to different physical for different processes, as I understand it. Wikipedia says: "Therefore, modern <a href="http://en.wikipedia.org/wiki/32-bit" title="32-bit">32-bit</a> x86 operating systems use the LDT very little, primarily to run legacy <a href="http://en.wikipedia.org/wiki/16-bit" title="16-bit">16-bit</a> code." I do not know, what LDT has to do with TLS. Can you explain this?</div>
<br></div>So, all in all, things to do:<br></div>1. Add threads to x86 (Or x86 is dead now?)<br></div>2. Fix sb-concurrency (and possibly other pitfalls) in x86-64<br></div>