https://sourceware.org/bugzilla/show_bug.cgi?id=30360
Vladimir Mezentsev <vladimir.mezentsev at oracle dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
--- Comment #1 from Vladimir Mezentsev <vladimir.mezentsev at oracle dot com>
---
We interpose a lot of libC functions (dlopen, fork, pthread_create, etc.).
Some of these functions have versions. For example,
% nm -D /lib64/gprofng/libgp-collector.so | grep thread_create@ | sort
000000000004b420 T pthread_create@GLIBC_2.34
000000000004b490 T pthread_create@GLIBC_2.17
000000000004b500 T pthread_create@GLIBC_2.2.5
000000000004b570 T pthread_create@GLIBC_2.1
000000000004b5e0 T pthread_create@GLIBC_2.0
Our library does not set the default version for symbols.
This is correct because we don't know which libC will be used.
gcc and g++ links differently the version symbols when the default version is
not set.
c-linker is using our pthread_create@GLIBC_2.34 and c++-linker is using our
pthread_create@GLIBC_2.0 by default.
The current implementation of the interposed functions is:
If we are in our pthread_create@GLIBC_<NN>,
we use dlvsym (dlflag, "pthread_create", "GLIBC_<NN>") to find and call the
same function from libC.
In the test above, pthread_create@GLIBC_2.0 is not in the current libC.
We need to call the default pthread_create from libC.
I want to prepare this fix.
--
You are receiving this mail because:
You are on the CC list for the bug.
