DragonFly kernel List (threaded) for 2005-05
Re: patch #2 to add pointer to errno in TCB (Re: The time has come for a kernel interfacing library layer)
com> <20050510193240.GB11095@xxxxxxxxxxxxxxxxx> <200505102246.j4AMkSvb025033@xxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
X-Trace: 1115786517 crater_reader.dragonflybsd.org 717 184.108.40.206
Xref: crater_reader.dragonflybsd.org dragonfly.kernel:8418
Matthew Dillon wrote:
> As of patch set #2, the RTLD doesn't depend on the TLS at all right now.
> i.e. allocate_initial_tls() has been removed (it's #if 0'd out in patch
> set #2). The system call set in libc_rtld stores errno as a simple
> non-TLS global variable.
> I would love to get rid of the oldtcb handlng. Let me integrate that into
> my patch set, though, don't do commits to those files (they will create
> more cvs conflicts that I really don't want to waste time dealing with).
Matt, please get rid of oldtcb parameter, since it comes from FreeBSD
libpthread(M:N), where rtld and libc do not know how large a tcb should
be, since libthread_xu and libthr on FreeBSD are pure 1:1, I don't need
the resizable and relocatable tcb feature, all I need are tls_get_tcb()
tls_get_tcb get current tcb or initial tcb (if it was already setup by
rtld or libc), then, in tcb_ctor(), if it is for initial thread, I will:
struct tls_tcb *tcb;
tcb = tls_get_tcb();
tcb = _rtld_allocate_tls(...);
tcb->tcb_pthread = thread;
> The thread libraries currently do some weird things which I still do
> not fully understand. For example, libthread_xu has a _tcb_ctor()
> function which is passed an 'old_tcb' parameter. I don't know if
> the parameter is ever non-NULL but if it is we have a problem.
> All the tls allocation calls in libc_r pass NULL for oldtcb so I think
> we are safe there.
Please see my above answer.
> The _init_tls override mechanism that is the natural extension to the
> the current patch #2 (I will put the weak associations in patch #3)
> neatly solves the problem by making libc responsible for setting up
> the TLS for the program and by giving the threading libraries a chance
> to get their hooks in at that point to e.g. set up the tcb_pthread
> pointer, not to mention tcb_errno_p and other fields in the future.
It is a good idea to allow thread library to involve initial stage
for example _init_tls(). but I think the _init_tls in libc is too
complex for thread library, what I want to see another hook:
it will be called in libc's initial stage. I don't need relocatable
> I think I do want to keep the RTLD independant. It makes a lot of sense,
> especially since we want to support multiple threading libraries,
> because it really isolates the RTLD's function set and makes it far less
> likely that problems and incompatibilities will be introduced.
> This does mean that the RTLD needs its own syscall set, but it doesn't
> mean that the RTLD has to hardwire the system calls. I believe that my
> syscall layer will work for both (and in fact the RTLD could even support
> a different OS version then the user program binary!).
> Matthew Dillon