Libptread bug? (resent)

[Zagorodnev, Grigory]

! I think this mail been sent in bad format last week, so I've resent it !

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
 Senior Software Engineer
 Software Technology Laboratory
--------------------------------