Porting sbcl to DragonFly

[vasily postnicov]

2013/3/30 Chris Turner <c.turner at 199technologies.com>

> On 03/30/13 00:16, vasily postnicov wrote:
>
>  So I have some questions:
>> 1. src/runtime/Config.x86-64-**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).
>> 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?
>>
>
> 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)
>
> To also clarify, our libpthread uses 1:1 model.
>
> If you get frustrated or finished with SBCL and want some other 'Low
> Hanging LISP Fruit',
> fixing up boehmgc should make ECL work properly, and will also help with
> other fun and interesting
> interpreters - see also:
>
> http://bugs.dragonflybsd.org/**issues/1525<http://bugs.dragonflybsd.org/issues/1525>
>
> ECL is a bit more straightforward of a LISP since it isn't doing as
> much code generation/low level stuff IIRC, instead relying on more
> 'standard' posixy stuff.
>
> Cheers and good luck!
>
> - Chris
>

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:

int arch_os_thread_init(struct thread *thread) {

#ifdef LISP_FEATURE_SB_THREAD
    int n;

    struct segment_descriptor ldt_entry = { 0, 0, SDT_MEMRW, SEL_UPL, 1,
                                            0, 0, 1, 0, 0 };

    set_data_desc_addr(&ldt_entry, thread);
    set_data_desc_size(&ldt_entry, dynamic_values_bytes);

    n = i386_set_ldt(LDT_AUTO_ALLOC, (union descriptor*) &ldt_entry, 1);
    if (n < 0) {
        perror("i386_set_ldt");
        lose("unexpected i386_set_ldt(..) failure\n");
    }
    FSHOW_SIGNAL((stderr, "/ TLS: Allocated LDT %x\n", n));
    thread->tls_cookie=n;
    arch_os_load_ldt(thread);

....... /* Skipped few lines */
}

int arch_os_thread_cleanup(struct thread *thread) {

#if defined(LISP_FEATURE_SB_THREAD)
    int n = thread->tls_cookie;

    /* Set the %%fs register back to 0 and free the ldt by setting it
     * to NULL.
     */
    FSHOW_SIGNAL((stderr, "/ TLS: Freeing LDT %x\n", n));

    __asm__ __volatile__ ("mov %0, %%fs" : : "r"(0));
    i386_set_ldt(n, NULL, 1);
#endif

    return 1;                  /* success */
}

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.

BTW, arch_os_thread_init, of course, is called from new thread, not from
parent thread.

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
32-bit<http://en.wikipedia.org/wiki/32-bit>x86 operating systems use
the LDT very little, primarily to run legacy
16-bit <http://en.wikipedia.org/wiki/16-bit> code." I do not know, what LDT
has to do with TLS. Can you explain this?

So, all in all, things to do:
1. Add threads to x86 (Or x86 is dead now?)
2. Fix sb-concurrency (and possibly other pitfalls) in x86-64
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.dragonflybsd.org/pipermail/users/attachments/20130331/221469ac/attachment-0002.html>