Ask for suggestion of building a liblkl.so without libc

[liuyuan10]

dlmopen of liblkl.so brings so many troubles and one that I can't get around is limitation of static TLS. Now liblkl.so depends on libc which may use static TLS. At runtime, the amount of static TLS is fixed so dlmopen may fail.

To overcome this, I'd like to introduce another layer like struct lkl_libc. It's similar to lkl_host_ops but only accessible in tools/lkl/lib. So struct lkl_libc looks like:

struct lkl_libc {
memcpy
memset
strcpy...
}

And there will be a lkl_libc.c which is shared by both posix-host and nt-host.

A new host called nonlibc-host is added that provides empty lkl_host_ops and lkl_libc so the final liblkl.so doesn't depends on libc at all. In application, at run time, after dlmopen it, lkl_host_ops and lkl_libc is properly set so all liblkl.so instances share the same libc/libpthread.

I guess it may also simplify the work in #255 where a new libc implementation can be easily integrated.

Please let me know your opinions. Thanks

[thehajime]

just curious - are you going to re-implement pthread used in posix-host.c ?

I guess it may also simplify the work in #255 where a new libc implementation can be easily integrated.

actually #255 has two libc implementation when it's integrated with frankenlibc - 1) frankenlibc, an implementation of libc functions for underlying host (linux, netbsd, freebsd, qemu-arm, etc) used by host_ops (or rump hypercalls), and 2) musl-extended libc for upper applications.

so, though i'm not quite sure what the @liuyuan10's original guess is, there is already lkl_libc.c-ish implementation out there (note: native thread/posix thread is not supported yet).

another question would be: isn't reimplementation of libdl.so enough to overcome the static TLS issue ?

[liuyuan10]

Embarrassing. Turns out I don't have to use dlmopen but rename liblkl.so multiple times and I'm able to load LKL tens of times this way. It helps to avoid all the troubles from dlmopen and I'm happy to get rid of it.

Closing it... Sorry for the noise.