Use solely offset tables in the Haskell world

[gkaracha]

Depends on #782.

Following #782, this PR switches all symbol tables in Haskell land into offset tables; the rts still deals solely with symbol tables. Along with it comes a lot of renaming ("symbol table" => "offset table"), and type changes (Word32 used for offsets, as opposed to Int64 used for addresses).

[gkaracha]

@TerrorJack merely following the types, I partitioned genExportStaticObj into genStaticsExportStaticObj and genFunctionsExportStaticObj, but looking into their structure, I find genStaticsExportStaticObj to be a little weird (given that internally it calls genExportStaticFunc). FWIW I have yet to encounter a non-empty req.staticsExportsStatic in the rts 🤔

[gkaracha]

As an aside, I'd have preferred to use Word32 instead of Int32 so that all valid offsets are interpreted correctly (even things like 0x80000000), but the offset of DataSegment is a ConstI32, which takes an Int32 anyway.

[gkaracha]

Perhaps I should switch to Word32 and use fromIntegral; when #776 lands at least we'll know about this happening at compile time.

[dpulls]

🎉 All dependencies have been resolved !

[TerrorJack]

@gkaracha You should be able to completely remove the functionsExportsStatic field when generating the .req.mjs script in Asterius.Main. The genExportStaticObj function should only work with the data offset map, not function offset map.

This may sound unintuitive since genExportStaticObj handles Haskell function exports. But each static closure of an exported Haskell function is a data segment, so we're really dealing with data offsets here. I've no idea why I also did a functionsExportsStatic thing, but that should be redundant.

[gkaracha]

Also, I am leaving the following renamings for last, lest GitHub treats them as file deletions and additions..

Asterius.Passes.DataSymbolTable     => Asterius.Passes.DataOffsetTable
Asterius.Passes.FunctionSymbolTable => Asterius.Passes.FunctionOffsetTable

[gkaracha]

@gkaracha You should be able to completely remove the functionsExportsStatic field when generating the .req.mjs script in Asterius.Main. The genExportStaticObj function should only work with the data offset map, not function offset map.

This may sound unintuitive since genExportStaticObj handles Haskell function exports. But each static closure of an exported Haskell function is a data segment, so we're really dealing with data offsets here.

Wow, yes, that is unintuitive but now that you explained it it makes total sense. I'll fix that 👍

I've no idea why I also did a functionsExportsStatic thing, but that should be redundant.

Ah, that must have been me actually, when I separated the two sym_maps some time ago. I should have pointed out my confusion then I guess 😅

[TerrorJack]

Also, I don't think #776 is about to land any time soon. binaryen forcibly uses overflow behavior of integers when representing literals. For instance, the C API uses signed int64_t for i64 rep, and we need to model that in Int64 in Haskell, so when handling large literals safeIntegral panics.

Maybe we can change our IR a bit, always use Word32/Word64 to represent literals. I'll still need to look a bit into GHC's FFI to see whether this will become a footgun.

[gkaracha]

Also, I don't think #776 is about to land any time soon. binaryen forcibly uses overflow behavior of integers when representing literals. For instance, the C API uses signed int64_t for i64 rep, and we need to model that in Int64 in Haskell, so when handling large literals safeIntegral panics.

Maybe we can change our IR a bit, always use Word32/Word64 to represent literals. I'll still need to look a bit into GHC's FFI to see whether this will become a footgun.

I see. Well, for now this PR basically would fail in these corner cases just as much as we do already, so I guess it doesn't make much of a difference (and I'd definitely leave IR changes to a separate PR). Do you have a preference for Int32 vs. Word32?

[TerrorJack]

Let's stick with Int32 for now to keep the changes minimal.

Word32 offsets are fine since we don't stick them into ConstI32s.

[gkaracha]

Cool. Any other things to fix or are we just waiting for CI to finish? (I shall get started on updating #750 if you consider this one good to go)

EDIT: well, after I do the renaming also (#783 (comment)), that is.

[TerrorJack]

All lgtm now, would you push the SymbolTable.hs to OffsetTable.hs renamings? Then I'd hit the merge button :)

[gkaracha]

There, all done 🙂