[PATCH] D90948: [WebAssembly] call_indirect issues table number relocs

Andy Wingo via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Feb 15 03:21:14 PST 2021


wingo added a comment.

In D90948#2556789 <https://reviews.llvm.org/D90948#2556789>, @wingo wrote:

> Thanks for patience with the delay here.  Paging this back in -- I will move the logic from `MC/WasmObjectWriter.cpp` to `WebAssemblyAsmPrinter.cpp` -- there I will iterate over all functions in the module, and if any of them `hasAddressTaken`, then I will ensure an `__indirect_function_table` definition exists and will be written to the output (setNoStrip).  We keep the hack that table symbols only go to the symbol table if they are marked as used in relocations.  If the reference types feature is enabled and an address-taken function is present in the module, the indirect function table will be explicitly marked `isUsedInReloc`.  Just broadcasting intention here so that there are no more late surprises :)

@tlively: So, this appears to work.  However I ran into a problem in WebAssemblyAsmParser -- it needs to do this same logic, if a function-to-pointer cast happens in assembly, we should ensure that the indirect function table is present in the output.  Before, this case was caught by WasmObjectWriter.  E.g. test/MC/WebAssembly/weak-alias.s has:

  load_hidden_func:
      .functype   load_hidden_func () -> (i32)
      global.get  __table_base
      i32.const   hidden_func at TBREL
      i32.add
      end_function

But with no call_indirect, the output doesn't have __indirect_function_table, as it should.

I could check if any instruction is `i32.const` or `i64.const` with the operand being a symbol, and check that the symbol is a function, but that is gross :/  I will continue to think about this but any pointers you might have would be welcome.  I lean towards my previous solution, fwiw.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D90948/new/

https://reviews.llvm.org/D90948



More information about the llvm-commits mailing list