[llvm-bugs] [Bug 48214] New: ThinLTO doesn't import .symver directives

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=48214

            Bug ID: 48214
           Summary: ThinLTO doesn't import .symver directives
           Product: new-bugs
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
          Assignee: unassignedbugs at nondot.org
          Reporter: hans at chromium.org
                CC: htmldeveloper at gmail.com, llvm-bugs at lists.llvm.org

Consider this example:

$ cat /tmp/a.c
extern int foo();

int main(int argc, char **argv) {
  return foo(argc);
}

$ cat /tmp/b.c
#include <math.h>

__asm__(".symver pow, pow at GLIBC_2.2.5");

int foo(int x) {
  return (int)pow(3, x);
}


What the code is doing is that b.c uses the pow() symbol from glibc, but
instead of the default version (GLIBC_2.29 on my system), it uses the .symver
directive to request a specific version:

$ bin/clang -O2 -fuse-ld=lld /tmp/a.c /tmp/b.c -lm -o foo && objdump -T foo |
grep pow
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 pow


However, with ThinLTO that no longer works:

$ bin/clang -O2 -fuse-ld=lld -flto=thin /tmp/a.c /tmp/b.c -lm -o foo && objdump
-T foo | grep pow
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.29  pow
0000000000000000      DF *UND*  0000000000000000  GLIBC_2.2.5 pow


I believe what's happening here is that when ThinLTO imports foo() into the IR
Module for a.c, it also imports the pow() declaration, but it doesn't import
the inline asm string, and so the .symver directive isn't applied in that
module.


We hit this in Chromium, which adds these directives to math.h in its sysroot
in order to control what versions of these symbols to link against.
(crbug.com/1105253)

I understand this is a somewhat unorthodox use of the directive -- normally
.symver is used on function definitions when building a shared library, not on
function declarations. However
https://sourceware.org/binutils/docs/as/Symver.html#Symver does make it sound
like this is a supported use: "If the symbol /name/ is not defined within the
file being assembled, all references to /name/ will be changed to
name2 at nodename."

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20201118/14201ada/attachment.html>