cvs commit: src/sys/sys tls.h src/lib/libc/gen tls.c src/lib/libthread_xu/arch/amd64/amd64 pthread_md.c src/lib/libthread_xu/arch/i386/i386 pthread_md.c src/libexec/rtld-elf rtld.c rtld.h rtld_tls.h src/libexec/rtld-elf/i386 reloc.c

[Joerg Sonnenberger]

On Mon, Mar 28, 2005 at 10:06:24AM -0800, Matthew Dillon wrote:
> 
> :
> :On Sun, Mar 27, 2005 at 07:33:20PM -0800, Matthew Dillon wrote:
> :>   1.5       +35 -23    src/libexec/rtld-elf/i386/reloc.c
> :
> :The check for libc already having allocated a TCB is unnecessary,
> :the program is pretty much hosed if this happens.
> :
> :Joerg
> 
>     There is some sort of init function in libc which... see
>     /usr/src/lib/libc/gen/tls.c, _init_tls(), which appears to run
>     before anything else, at least for static builds.  I don't like
>     the idea of not supporting the possibility that an initial TLS might
>     already be set-up before the RTLD runs, so I went for a generic
>     solution.

And static programs by definition don't run the rtld :)

I can think of some problems occuring if that would ever happen.
Like libc changing the TLS and rtld not keeping the new value.
Or libc and rtld having difference addresses e.g. for errno.

>     An even larger issue is the fact that we seem to repeat the TLS and
>     dynamic segment management code something like three times between
>     libc and rtld.  I'd prefer that code to exist just once, though I
>     don't see an easy way to do it in just one place at the moment.

I'm thinking about that too. I don't like to cross-reference source code,
but we might but some common code into libc, which rtld is linked against.
Well, -lc_pic, but that's minor :)

Joerg