https://bugs.llvm.org/show_bug.cgi?id=36039
Bug ID: 36039
Summary: [WebAssembly] must emit call_indirect for weak
undefined symbols
Product: libraries
Version: trunk
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: Backend: WebAssembly
Assignee: unassignedb...@nondot.org
Reporter: n...@realvnc.com
CC: llvm-bugs@lists.llvm.org
When a Wasm object file calls an undefined weak symbol, the `call` instruction
should not be used; instead the backend should emit a `call_indirect`
instruction.
The problem is that a `call` instruction MUST have a valid operand for the Wasm
file to validate. And, the final linked output must certainly validate. If the
symbol is undefined and weak, then the final linked output will have no
corresponding Wasm import or Wasm function to use as the operand of the call
instruction.
=== failing code ===
extern int strongExt(void);
extern __attribute__((weak)) int weakExt(void);
void callExts(void) { strongExt(); if (weakExt) weakExt(); }
// Compile with:
// clang --target=wasm32-unknown-unknown-wasm -nostdlib -o /tmp/test.wasm \
// /tmp/test.c -Wl,--allow-undefined -Wl,--no-entry
// LLD fails on an assertion.
Even though the call is guarded with a check for whether the function is
defined, the call instruction is still present.
I believe that calls to all weak undefined symbols will have to be made
indirectly. This isn't as bad as it sounds: weak but defined symbols are fine,
since the call instruction is safe to emit; and, for weak undefined symbols
you'd need a conditional check anyway to be safe at runtime, which would have
the same effect of putting the function in the table. So, I don't believe that
this will result in significant bloat on the function table.
For completeness:
An alternative would be a linker-generated function stub with the correct
signature which calls unreachable, to use as the operand of the `call`
instruction.
--
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
