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

Sam Clegg via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Nov 10 21:18:02 PST 2020


sbc100 added a comment.

In D91203#2387683 <https://reviews.llvm.org/D91203#2387683>, @dblaikie wrote:

> 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?

At the C/C++/llvm layers all pointer are the same size (i.e. 64bit on wasm64), including function pointers.   The difference with wasm is that those functions pointers are not in the same address space as the bytecode offsets used in the DWARF information.

Function pointers in C/C++llvm are indexes into the indirect function pointer table that wasm maintains.

IIUC code offsets in DWARF are byte offsets into the wasm bytecode file (which it completely inaccessible from C/C++/llvm).


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

https://reviews.llvm.org/D91203



More information about the llvm-commits mailing list