patch #2 to add pointer to errno in TCB (Re: The time has come for a kernel interfacing library layer)
David Xu
davidxu at freebsd.org
Tue May 10 21:43:06 PDT 2005
com> <20050510193240.GB11095 at xxxxxxxxxxxxxxxxx> <200505102246.j4AMkSvb025033 at xxxxxxxxxxxxxxxxxxxx>
In-Reply-To: <200505102246.j4AMkSvb025033 at xxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit
Lines: 68
Message-ID: <42818d14$0$717$415eb37d at 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 at xxxxxxxxxxxxx>
David Xu
More information about the Kernel
mailing list