Re: libpthread.a:_pthread_initialize_minimal_internal not called if statically build

[Carmelo Amoroso <carmelo73 at gmail dot com>]

Carmelo Amoroso wrote:
> Hi All,
> I executed nptl/tst-raise1 test statically linked using glibc-2.5 on
> sh4 (and glibc-2.4.4 on x86) using the following command:
> <sh4-linux->gcc -static -D_GNU_SOURCE -D__USE_GNU -std=gnu99 -Os
> tst-raise1.c -lpthread -o tst-raise1
>
> Running the executable on SH4 platform (and x86 host - Fedora Core5) I
> got the following message:
> "first raise failed: Invalid argument"
>
> while it works fine using DSO.
>
> The 'raise' implementation (nptl/sysdeps/unix/sysv/linux/pt-raise.c)
> assumes that thread descriptor has been already filled with proper
> values (tid and pid in this case).
> This should be done by _pthread_initialize_minimal_internal
> (libpthread.a:init.o), but when  statically linked, the
> _pthread_initialize_implementation is resolved into libc.a:libc-tls.o,
> that takes care of initializing tls data only.
> So raise fails due to invalid tid and pid argument.
>
> A solution could be removing the raise from libpthread.a and use the
> working implementation into libc.a (as glibc-2.3.4 did).
> But we still use the wrong _pthread_initialise_minimal when linking
> with "-static -lpthread".
Well, I did further test and verified that calling pthread_create(),
the object pthread_create.o needs the symbol __xidcmd to be resolved.
This will force the linker to load the libpthread.a:init.o that
will provide the required _pthread_initialize_minimal function.

So the issue is still present in the test case tst-raise1 because
it doesn't call pthread_create. Any other scenario using the
pthread_create will not exploit this issue... but potentially
present.
> I don't know what other problems this could arise.
>
> Any comments are welcome.
> If you think I'm right, I can file a bug.
>
> Regards,
> Carmelo