This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Unexpected difference between _CS_GNU_LIBPTHREAD_VERSION and actual version
- From: Elmar Krieger <elmar at cmbi dot ru dot nl>
- To: libc-alpha at sourceware dot org
- Date: Tue, 12 Dec 2006 13:14:36 +0100
- Subject: Unexpected difference between _CS_GNU_LIBPTHREAD_VERSION and actual version
Hi everyone,
my program is dynamically linked with libpthread, and
confstr(_CS_GNU_LIBPTHREAD_VERSION,...) returns
NPTL 2.3.3 (on Fedora Core 3)
But if I analyze the program with GDB, I get output like:
Dump of assembler code for function pthread_attr_setaffinity_np@@GLIBC_2.3.4:
0x00a03ea0 <pthread_attr_setaffinity_np@@GLIBC_2.3.4+0>: push %ebp
0x00a03ea1 <pthread_attr_setaffinity_np@@GLIBC_2.3.4+1>: mov %esp,%ebp
0x00a03ea3 <pthread_attr_setaffinity_np@@GLIBC_2.3.4+3>: push %edi
0x00a03ea4 <pthread_attr_setaffinity_np@@GLIBC_2.3.4+4>: push %esi
0x00a03ea5 <pthread_attr_setaffinity_np@@GLIBC_2.3.4+5>: push %ebx
0x00a03ea6 <pthread_attr_setaffinity_np@@GLIBC_2.3.4+6>: sub $0x10,%es
p
0x00a03ea9 <pthread_attr_setaffinity_np@@GLIBC_2.3.4+9>: mov 0x10(%ebp
),%esi
0x00a03eac <pthread_attr_setaffinity_np@@GLIBC_2.3.4+12>: mov 0xc(%ebp)
So why does confstr return "2.3.3" while the actual symbols indicate "2.3.4"?
This kills me because the function prototype of pthread_attr_setaffinity_np has
been changed from 2.3.3 to 2.3.4 (if I read the libc sources correctly), so I
have to determine at run-time which parameters to pass in which order, after
obtaining the entry point with dlsym. (My program must also run on older
libpthreads that don't know pthread_attr_setaffinity_np yet).
Any more secure way than using 'confstr' to determine at runtime which arguments
pthread_attr_setaffinity_np expects?
Many thanks for your help,
Elmar
P.S.: If I look at /lib/tls/libpthread.so.0 in a hex-editor, I see that it
contains @@GLIBC_2.3.3 and @@GLIBC_2.3.4 symbols.