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

Sam Clegg via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Jan 29 08:22:29 PST 2021


sbc100 added a comment.

In D90948#2530072 <https://reviews.llvm.org/D90948#2530072>, @tlively wrote:

> In D90948#2530061 <https://reviews.llvm.org/D90948#2530061>, @wingo wrote:
>
>> In D90948#2528890 <https://reviews.llvm.org/D90948#2528890>, @tlively wrote:
>>
>>> I'm also not 100% sure of how things work today, but I hope it wouldn't be too difficult to emit the MVP table precisely when necessary by seeing whether or not it would be empty immediately before writing out the final binary. I'm perfectly willing to believe that I'm missing something that prevents that from working, though.
>>
>> Unfortunately this is not the case.  You can still have
>>
>>   void call(void (*f)(void)) {
>>     f();
>>   }
>>
>> in the compilation unit, causing `call_indirect` to be emitted but no function pointer definition.
>
> I meant that the linker should choose whether to emit the table into the final binary by checking whether it would be empty or not. So in this example, whether or not this compilation unit had a table in its object file, the linker would see that some function has its address taken (in the caller of `call`) and needs to be allocated a table slot. Since the table wouldn't be empty, the linker emits the table in the final binary.

Ah yes I remember what that doesn't work.

Because you can have this code:

a.o

  void call(void (*f)(void)) {
     if (f) {
        f();
     }
  }

b.o:

  void foo() { 
    call(NULL);
  }

Now you have a program that contains call_indirect but no function pointers.   Its kind of annoying that the wasm standard makes this invalid but that is the current state.  I think I have bought this up before in the standards discussions but perhaps we could re-litigate?   WTYT tlively, would this make sense as a spec change?


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