[PATCH] D91203: [WebAssembly] Fixed wasm64 DWARF using 64-bit code pointer sizes

[David Blaikie via Phabricator via llvm-commits]

dblaikie added a comment.

In D91203#2386990 <https://reviews.llvm.org/D91203#2386990>, @aardappel wrote:

> @dblaikie Confusingly, these are all different: function pointers at runtime (in a Wasm VM) are 32-bit indices. LLVM function pointers are 64-bit in wasm64 for consistency, but get truncated when lowered in Isel. Then here we have a 3rd kind of code pointer, just for DWARF, since Wasm doesn't have the concept of a pointer to an instruction inside a function (which DWARF needs for DW_AT_low_pc, and we need to relocate).
>
> And yes, if this is also used for globals, and there is an architecture for which code pointers would be smaller than global pointers, then this patch would break them.
>
> An alternative solution for Wasm would be to just go along with the expected 64-bit size for DW_FORM_addr, but that would mean wasted space, and a new reloc type for us. Also means DWARF data between wasm32 and wasm64 is different.

Not sure we're perhaps talking about the same thing or there's some overlap/confusion.

What's the actual sizeof(int*) and sizeof(int(*)()) if I printed those out in some C++ code compiled to wasm? The size has to be known by the frontend/at the language level, so it can't change due to lowering.
If I have an array of int*, that array needs elements of a size known by the frontend/language-level, similarly if I have an array of int(*)() - and in both cases I'd need to use some relocation to fill in my array initializer that initializes that array?

I'd suggest doing whatever happens for that case in DWARF too.


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

https://reviews.llvm.org/D91203