Re: patch #2 to add pointer to errno in TCB (Re: The time has come for a kernel interfacing library layer)

[David Xu <davidxu@xxxxxxxxxxx>]

com> <20050510193240.GB11095@xxxxxxxxxxxxxxxxx> <200505102246.j4AMkSvb025033@xxxxxxxxxxxxxxxxxxxx>
In-Reply-To: <200505102246.j4AMkSvb025033@xxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 68
Message-ID: <42818d14$0$717$415eb37d@xxxxxxxxxxxxxxxxxxxxxxxxxxxxxx>
NNTP-Posting-Host: 221.12.27.25
X-Trace: 1115786517 crater_reader.dragonflybsd.org 717 221.12.27.25
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;
	if (initial)
		tcb = tls_get_tcb();
	else
		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:
	_thread_init();
it will be called in libc's initial stage. I don't need relocatable
initial tls.

>     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!). 
> 
> 					-Matt
> 					Matthew Dillon 
> 					<dillon@xxxxxxxxxxxxx>

David Xu