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

[Andy Wingo via Phabricator via llvm-commits]

wingo added a comment.

Hi :)

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

> What do you think about this scheme:
>
> - MVP object files signal table usage by importing or not importing a table.
> - Reftypes object files signal table usage by a table symbol and relocations, even for the default table (table 0).
> - The linker emits table zero if any non-reftypes object imports a table **or** if the default table symbol is live.

Just for clarity, this differs from where I was initially going in two ways:

- I had made it so that MVP object files could have symbols and TABLE_NUMBER relocs, but this proved incompatible with old linkers.  Therefore table symbols and TABLE_NUMBER relocs will be emitted only if reftypes is enabled.
- I didn't have any special logic to keep __indirect_function_table assigned to table number 0, assuming that either all inputs or no inputs had table symbols and relocatable table references.  This is incompatible with linking to old MVP object files whose table references are not relocatable.

So I will first add the logic to the linker that it will assign table number 0 to __indirect_function_table, if it is present.

> This scheme has the following valuable properties:
>
> - The MVP object file ABI is not changed. MVP object files do not use new symbol or relocation types.
> - MVP and reftypes object files can be linked together.

Agreed.

> - If all objects that use the default table have reftypes enabled, we get the full precision of emitting the table only if its symbol is live.

It's "fullish" precision.  TABLE_INDEX relocations for function pointer bitcasts don't explicitly reference the table, so instead they `setNoStrip` on the indirect function table.  There can be cases where the linker omits the function pointer, causing the function table to no longer be necessary, but the linker can't know that.

> - All feature detection happens in codegen, not in object writing.

Yes, for `call_indirect`.   But when we emit a function pointer at the MC layer -- either in data or in code -- we need that to cause the function table to be present.  For function pointers in code, i think we can find the feature set just fine, so that for reftypes we cause a symtab entry to be emitted for the function table.  But for function pointers in code I don't know a good way to do feature detection; do you have any ideas here?

Thanks for your patience with this small but gnarly problem!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D90948