[Bug dynamic-link/14932] dlsym(handle, "foo") and dlsym(RTLD_NEXT, "foo") return different result with versioned "foo"

["jakub at redhat dot com" <sourceware-bugzilla@sourceware.org>]

https://sourceware.org/bugzilla/show_bug.cgi?id=14932

Jakub Jelinek <jakub at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at redhat dot com

--- Comment #4 from Jakub Jelinek <jakub at redhat dot com> ---
I think changing this is highly undesirable, as written in
https://marc.info/?l=glibc-alpha&m=98313802001691&w=2
the current dlsym behavior provides ABI stability, no matter what you run the
program against it will always return the same symbol.
While if it returns the default symbol (there doesn't need to be any), it would
change behavior depending on what glibc is used at runtime.
Say, you compile/link your program against glibc 2.5, which provides foobar
symbol say at @@GLIBC_2.5, later glibc 2.37 comes and will have
foobar @GLIBC_2.5 and @@GLIBC_2.37.  Some versioned symbols are solely about
adding features while keeping the ABI the same, say it handles another bitmask
in argument that was previously rejected with -1/setting errno or similar, say
regexec, that perhaps can be handled.  But in other cases the ABI of the
function changes, adds/removes argument or e.g. what some argument points to
changes layout (and not just in glibc, but in any versioned shared library).
You really don't want your old programs to suddenly break because of that.

Basically, dlsym should follow what happens when you link against a shared
library before symbol versioning has been added to it (e.g. very old glibc).

sanitizers need to be fixed so that the sanitizer libraries are also symbol
versioned and when they wrap some glibc symbols, they follow the versioning
there, i.e. if they wrap regexec and regexec is on a particular architecture
regexec@GLIBC_2.2.5 and regexec@@GLIBC_2.3.4, then it wraps both of them
and each of those uses dlvsym to find the corresponding symbol in glibc.

-- 
You are receiving this mail because:
You are on the CC list for the bug.