https://bugs.kde.org/show_bug.cgi?id=428909
--- Comment #11 from Mark Wielaard <m...@klomp.org> --- Hi Paul, (In reply to Paul Floyd from comment #10) > I'll attempt to add as many explanations as possible. Thanks, sorry for being so slow. It doesn't really help (IMHO) that we are trying to fix an issue with newer glibc and musl at the same time. > First, the true nature of the problem on Fedora 33. For some very bizarre > reason, pthread_cond_destroy is no longer in libpthread: > > paulf> nm /lib64/libpthread.so.0 | grep cond_destroy > U __pthread_cond_destroy@@GLIBC_PRIVATE > > instead it is in libc > > paulf> nm /lib64/libc.so.6 | grep cond_destroy > > [snip loads more] > 0000000000086440 T pthread_cond_destroy@GLIBC_2.2.5 > 00000000000869f0 T pthread_cond_destroy@@GLIBC_2.3.2 OK. I talked to a glibc hacker and their intention is to (eventually) move everything from libpthread.so.0 into libc.so.6: https://sourceware.org/legacy-ml/libc-alpha/2019-10/msg00080.html So it seems we should try to wrap all pthread functions we need to intercept in both pthread.so and libc.so to be future proof (and work with older glibc versions where all, or most, pthread_ functions are still in libpthread.so). > DRD and Helgrind are doing essentially the sme thing for the intercepts, but > differ a bit in the details. For DRD, see drd_pthread_intercepts.c where the > PTH_FUNCS macro generates 3 wrapper functions covering "name", "name@*" and > "name$*". Bart extended this for both libc and libpthread (but only > libthread with MUSL) Is libthread (without p) the name of the pthread_ functions library in MUSL? > Hence I now see > > paulf> nm vgpreload_drd-amd64-linux.so | grep pthread | grep cond | grep > destroy > U pthread_cond_destroy > 0000000000017c90 T _vgw00000ZZ_libcZdsoZa_pthreadZucondZudestroy > 0000000000017f70 T _vgw00000ZZ_libcZdsoZa_pthreadZucondZudestroyZAZa > 0000000000018250 T _vgw00000ZZ_libcZdsoZa_pthreadZucondZudestroyZDZa > 0000000000017e00 T _vgw00000ZZ_libpthreadZdsoZd0_pthreadZucondZudestroy > 00000000000180e0 T _vgw00000ZZ_libpthreadZdsoZd0_pthreadZucondZudestroyZAZa > 00000000000183c0 T _vgw00000ZZ_libpthreadZdsoZd0_pthreadZucondZudestroyZDZa OK, for this I always need to reread the Z-encoding description in pub_tool_redir.h So libcZdsoZa is the normal (glibc) libc.so* And libpthreadZdsoZd0 is the normal (glibc) libpthread.so.0 The ZAZa variant is @* And ZDZa is $* I assume we need the @* variant to intercept any versioned symbols. I am not sure why we need the $* variants, what does that match? > Helgrind is more on a case by case basis (which means the code is a bit > longer but only the required wrappers are generated). So now I see > > paulf> nm vgpreload_helgrind-amd64-linux.so | grep pthread | grep cond | > grep destroy > 000000000000a4f9 t pthread_cond_destroy_WRK > 000000000000d87d W _vgw00000ZZ_libcZdsoZa_pthreadZucondZudestroyZAZa > 000000000000d87d T _vgw00000ZZ_libpthreadZdsoZd0_pthreadZucondZudestroyZAZa > > The difference here is that DRD has 3 separate functions whilst Helgrind has > just one plus an alias. They both work the same way with the redirection > mechanism - they're just symbols and calling them does the same thing. OK, and drd uses VG_WRAP_FUNCTION_ZZ from pub_tool_redir.h and helgrind uses I_WRAP_SONAME_FNNAME_ZZ from valgrind.h. Which seem identical, but use slightly different macro expansions. So here we only care about the versioned variants (ZAZa). And the one in libc.so.* is weak (why?) > The differences between Linux and other OSes (Solaris, FreeBSD and macOS) > concern the names of the libc / libppthread libraries and the mangling used). Right, I see them defined in pub_tool_redir.h as VG_Z_LIBC_SONAME and VG_Z_LIBPTHREAD_SONAME -- You are receiving this mail because: You are watching all bug changes.
