[llvm-bugs] [Bug 35383] New: WASM backend fails on aliased symbols

[via llvm-bugs]

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

            Bug ID: 35383
           Summary: WASM backend fails on aliased symbols
           Product: libraries
           Version: trunk
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: WebAssembly
          Assignee: unassignedbugs at nondot.org
          Reporter: ncw at realvnc.com
                CC: llvm-bugs at lists.llvm.org

When creating aliased symbols, the WASM backend seems to get mixed up -
possibly by assuming that each function maps 1-to-1 to a symbol?

Full testcase:

####### test.c #######
static void dummy(void) {}
extern void __attribute__((weak, alias("dummy"))) __dothing(void);
void testFunc(void) { __dothing(); }

####### Commandline #######
> $LLVM/clang --version
clang version 6.0.0 (trunk 318652)
Target: wasm32-unknown-unknown-wasm
Thread model: posix
> $LLVM/clang -Oz -c -o test.o test.c

####### Output #######
> $WABT/wasm2wat test.o
(module
  (type (;0;) (func))
  (func $dummy (type 0))
  (func $testFunc (type 0)
    call $dummy)
  (table (;0;) 0 anyfunc)
  (memory (;0;) 0)
  (export "dummy" (func $dummy)) ; marked as "local" for lld
  (export "testFunc" (func $testFunc))
  (export "__dothing" (func $dummy))) ; marked as "weak" for lld


The problem is that the definition of "$testFunc" has been linked against the
symbol "$dummy" directly, rather than to the weak exported symbol "$__dothing".

This style of programming seems to be common in systems applications, such as
Musl libc (which I have distilled this test case from).  The local function
should link against the weak symbol, which will be resolved according to
whichever object exports that symbol most strongly. (In this case, the WASM
file that clang outputs has correctly-annotated the "export" entries using its
custom "linking" section.)

-- 
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/20171122/0b1140ed/attachment.html>