https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99814
--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> --- (In reply to Alex Richardson from comment #5) > Does the sanitizer runtime library include the > https://reviews.llvm.org/D96348 patch? > > IMO the real issue is that dlsym() with RTLD_NEXT selects the oldest > versioned symbol. Not sure why that behaviour was chosen. > I'm sure there are lots of other sanitizer interceptors that are also > affected by https://sourceware.org/bugzilla/show_bug.cgi?id=1319. dlsym behavior matches the behavior of normal symbol lookup resolution. When glibc (or some other libraries) started, it was unversioned and later symbol versions were added to it. When linking against the very old glibc, libraries or binaries would use unversioned symbols and so that for ABI compatibility naturally needs to be resolved against the oldest symbol version. Libraries/binaries linked against newer glibc versions then have versioned symbols and use both the symbol name and symbol version in symbol lookup (i.e. as dlvsym). For dlsym, one doesn't really know in which era the library or binary has been linked against and what it expects, it could be very old binary or newer or most recent, and if the same symbol has multiple symbol versions, which one to choose is unknown. So, for symbols with more than one symbol version one should use dlvsym instead of dlsym. Ideally, libsanitizer shared libraries would be symbol versioned, for its own APIs with some sanitizer specific symbol version(s), for the symbols it intercepts from glibc with the symbol versions from glibc it was configured against, and for symbols with multiple symbol versions one should have multiple interceptors, which if they call the intercepted function should use dlvsym. That would mean at library configure time scaning glibc symbol versions and deciding on the *san version scripts and predefined macros based on that.
