[llvm-bugs] [Bug 36039] New: [WebAssembly] must emit call_indirect for weak undefined symbols

[via llvm-bugs]

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: unassignedbugs at nondot.org
          Reporter: ncw at realvnc.com
                CC: llvm-bugs at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20180122/782a0471/attachment.html>