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

Wouter van Oortmerssen via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Nov 12 13:54:04 PST 2020


aardappel abandoned this revision.
aardappel added a comment.

After discussion with more Wasm+DWARF interested parties, it became clear that asking producers and consumers of DWARF to treat `DW_FORM_addr` as anything other than architecture dependent is going to be problematic, so the way forward for now is to make this field 64-bit on wasm64 as intended, and leave it 32-bit on wasm32.

I will thus abandon this patch (and revert the changes in the previous patch) and instead implement a 64-bit code pointer reloc for Wasm for the sake of DWARF, which overal will be easier to work with.

Consumers will need to either infer 64-bitness from the DWARF header or by checking memory section/import of the Wasm module, as other tools processing wasm64 (Memory64) do. If the current code relies on the DWARF header this may already work correctly transparently.

Memory64 as currently specced allows a single Wasm module to access multiple memories with a different bitness each. There are currently no tools that do this, but if they exist in the future, presumably they would have to write out the DWARF belonging to this mixed module as being wasm64.

My own wasm32 lowering pass in Binaryen is going to have to change the "architecture" of the associated DWARF data for example, not sure yet how difficult that will be.


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

https://reviews.llvm.org/D91203



More information about the llvm-commits mailing list