|
Message-ID: <87r2d5evvi.fsf@oldenburg2.str.redhat.com> Date: Mon, 21 Jan 2019 18:57:53 +0100 From: Florian Weimer <fweimer@...hat.com> To: musl@...ts.openwall.com Subject: Symbol versioning approximation trips on compat symbols On what appears to be current Alpine Linux (musl-1.1.19-r10), the following reproducer ###################################################################### cat > symver.c <<EOF void compat_function (void) { } __asm__ (".symver compat_function,compat_function@...VER"); void call_compat_function (void) { return compat_function (); } EOF echo "SYMVER { };" > symver.map cat > main.c <<EOF extern void call_compat_function (void); int main (void) { call_compat_function (); } EOF gcc -fpic -shared -o symver.so -Wl,--version-script=symver.map symver.c gcc -Wl,--rpath=. -o main main.c symver.so ###################################################################### fails with: $ ./main Error relocating ./symver.so: compat_function: symbol not found The problem is the compatibility symbol (one @ instead of @@). The dynamic linker is supposed to ignore the difference between the two, the default vs non-default version only matters to the link editor when processing an undefined symbol without a symbol version. In my case, I do not need symbol interposition and therefore can work around this, but I wonder if there is some sort of approved compile-time or link-time check to detect this issue. Unfortunately, the Alpine Linux toolchain (and part of the system) is built *with* symbol versioning support, so this does not appear to be straightforward. The actual application does not need to make the symbol interposable, so I can use a hidden alias within the DSO for PLT avoidance (and more configure checks to disable all this on targets which do not support *that*). Thanks, Florian
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.