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: unassignedb...@nondot.org
Reporter: n...@realvnc.com
CC: llvm-bugs@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._______________________________________________
llvm-bugs mailing list
llvm-bugs@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-bugs
