Libptread bug?

[Zagorodnev, Grigory]

Hi!
I having a problem with lpthread library on ia-64.

Could somebody check this report and clarify my questions:
        - is this problem already known?
        - is it fixed already?
        - if not, when it will be fixed?

The problem
-----------
Application statically linked against libpthread library causes segmentation fault.
There is a small coredumping testcase.

Conditions
----------
architecture: ia-64
glibc   ver.    : 2.2.2/2.2.3 (problem exists on both)
OS              : Red Hat Linux 7.1
cmd.line        : gcc -static foo.c -lpthread
source  :

        #include <setjmp.h>

        int main(){
                jmp_buf env;

                if( setjmp(env) == 0)
                        longjmp(env, 123);
        }

Investigation notes
-------------------
Executable causes segmentation violation at the beginning of 'longjmp' routine due to reading memory relative r13 (trhead pointer) register, while r13 contains debris value.

Reason is: application uses pthread implementation of 'longjmp' routine but pthread engine does not working. I.e. nobody controls contents of r13.

Pthread engine does not working just because it is not linked into the application (remeber we are using static version of the library). So, the actuall reason is here!

Looking at the libpthread.s contents I did not found any reference which can pull out pthread engine code after taking the 'longjmp':

        $ nm -o /usr/lib/libpthread.a | grep longjmp
        /usr/lib/libpthread.a:ptlongjmp.o:                 U __libc_longjmp
        /usr/lib/libpthread.a:ptlongjmp.o:                 U __libc_siglongjmp
        /usr/lib/libpthread.a:ptlongjmp.o:                 w __pthread_initialize
        /usr/lib/libpthread.a:ptlongjmp.o:                 w __pthread_initialize_minimal
        /usr/lib/libpthread.a:ptlongjmp.o:0000000000000000 T longjmp
        /usr/lib/libpthread.a:ptlongjmp.o:0000000000000140 T siglongjmp

At the same time, test passes on ia-32 with the same glibc/lipthread library (same version).
Symbols defined/undefined in ia32 libpthread.a are:
        $ nm -o /usr/lib/libpthread.a | grep longjmp
        /usr/lib/libpthread.a:ptlongjmp.o:         U __libc_longjmp
        /usr/lib/libpthread.a:ptlongjmp.o:         U __libc_siglongjmp
        /usr/lib/libpthread.a:ptlongjmp.o:         U __pthread_find_self
        /usr/lib/libpthread.a:ptlongjmp.o:         U __pthread_initial_thread
        /usr/lib/libpthread.a:ptlongjmp.o:         U __pthread_initial_thread_bos
        /usr/lib/libpthread.a:ptlongjmp.o:         w __pthread_initialize
        /usr/lib/libpthread.a:ptlongjmp.o:         w __pthread_initialize_minimal
        /usr/lib/libpthread.a:ptlongjmp.o:         U __pthread_manager_thread
        /usr/lib/libpthread.a:ptlongjmp.o:         U __pthread_manager_thread_bos
        /usr/lib/libpthread.a:ptlongjmp.o:         U __pthread_manager_thread_tos
        /usr/lib/libpthread.a:ptlongjmp.o:         U __pthread_nonstandard_stacks
        /usr/lib/libpthread.a:ptlongjmp.o:00000000 T longjmp
        /usr/lib/libpthread.a:ptlongjmp.o:000000a4 T siglongjmp
You can see that there are more undefined referencies and, as a result, all necessary parts of pthread engine will be linked into the application. Finally longjmp will work fine here.

Thanks and regards.
 Grigory Zagorodnev
 Software Technology Laboratory