New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Adapt to recent changes in `haskell-wasm` #1069

Closed

RyanGlScott opened this issue Mar 20, 2023 · 0 comments · Fixed by #1072

Labels

wasm

Contributor

RyanGlScott commented Mar 20, 2023

We will eventually need to update the haskell-wasm submodule in order to bring in changes from SPY/haskell-wasm#21. Before we can do this, however, we must adapt to some breaking API changes on the haskell-wasm side. Here is what I have found so far:

AnyFunc was renamed to FuncRef in SPY/haskell-wasm@4fb4da0, which affects this line in crucible-wasm:

crucible/crucible-wasm/src/Lang/Crucible/Wasm/Instantiate.hs

Line 420 in 5179065

do (Wasm.TableType (Wasm.Limit lmin _) Wasm.AnyFunc, addr) <- resolveTableIndex tableIndex im
The resultType field of Block had its type changed from ResultType to BlockType in SPY/haskell-wasm@b1874df. Similar changes were applied to the resultType of Loop and If in SPY/haskell-wasm@b816e04.

crucible-wasm is relying on ResultType being a list of types here:

crucible/crucible-wasm/src/Lang/Crucible/Wasm/Translate.hs

Lines 438 to 439 in 7942801

Wasm.Block{ resultType = vts, body = is } ->

do let n = length vts

And here:

crucible/crucible-wasm/src/Lang/Crucible/Wasm/Translate.hs

Lines 465 to 466 in 7942801

Wasm.If{ resultType = vts, true = true_is, false = false_is } ->

do let n = length vts

This means that we will need to convert the BlockType to a ResultType. We can take inspiration from how haskell-wasm does this here.

The text was updated successfully, but these errors were encountered:

RyanGlScott added the wasm label

RyanGlScott added a commit that referenced this issue


          crucible-wasm: Change AnyFunc to FuncRef

2b6cac5

This bumps the `haskell-wasm` submodule commit to
SPY/haskell-wasm@4fb4da0
and adjusts the code in `crucible-wasm` accordingly.

Part of #1069.

RyanGlScott added a commit that referenced this issue


          crucible-wasm: Adapt to Wasm's extend_N_S operations

188f550

This bumps the `haskell-wasm` submodule commit to
SPY/haskell-wasm@d61926e,
which adds unary operators corresponding to the signed extension operators
added in WebAssembly/spec#1144. I have added
corresponding Crucible translations based on the WebAssembly reference
interpreter.

Part of #1069.

RyanGlScott added a commit that referenced this issue


          crucible-wasm: Adapt to Assertion gaining an extra argument

01f73d7

This bumps the `haskell-wasm` submodule commit to
SPY/haskell-wasm@01e0ab8,
which gives `Assertion` an additional `Int` argument representing a line
number. We do not make use of this in `crucible-wasm`, so it is fine to ignore.

Part of #1069.

RyanGlScott added a commit that referenced this issue


          crucible-wasm: Adapt to multi-value Wasm proposal

c5d77bb

This bumps the `haskell-wasm` submodule to include the changes from
SPY/haskell-wasm@b1874df
and
SPY/haskell-wasm@b816e04,
which change the `Block`, `Loop`, and `If` instructions to use a `BlockType`
instead of a `ResultType`. This allows these instructions to have multiple
result values, as described in this WebAssembly proposal:
WebAssembly/spec#1145

To adapt the code on the `crucible-wasm` side, I have introduced a
`getBlockResultType` function to convert from a `BlockType` to a `ResultType`,
which is heavily inspired by a similar function in `haskell-wasm`. I have also
factored out some code shared in common between `translateFunction` and
`genInstruction`'s case for `Block` so that I do not have to conjure up a fresh
`BlockType` in `translateFunction`.

Part of #1069.

RyanGlScott added a commit that referenced this issue


          crucible-wasm: Change AnyFunc to FuncRef

98017b4

This bumps the `haskell-wasm` submodule commit to
SPY/haskell-wasm@4fb4da0
and adjusts the code in `crucible-wasm` accordingly.

Part of #1069.

RyanGlScott added a commit that referenced this issue


          crucible-wasm: Adapt to Wasm's extend_N_S operations

1175a39

This bumps the `haskell-wasm` submodule commit to
SPY/haskell-wasm@d61926e,
which adds unary operators corresponding to the signed extension operators
added in WebAssembly/spec#1144. I have added
corresponding Crucible translations based on the WebAssembly reference
interpreter.

Part of #1069.

RyanGlScott added a commit that referenced this issue


          crucible-wasm: Adapt to Assertion gaining an extra argument

0e9202f

This bumps the `haskell-wasm` submodule commit to
SPY/haskell-wasm@01e0ab8,
which gives `Assertion` an additional `Int` argument representing a line
number. We do not make use of this in `crucible-wasm`, so it is fine to ignore.

Part of #1069.

RyanGlScott added a commit that referenced this issue


          crucible-wasm: Adapt to multi-value Wasm proposal

67d91c9

This bumps the `haskell-wasm` submodule to include the changes from
SPY/haskell-wasm@b1874df
and
SPY/haskell-wasm@b816e04,
which change the `Block`, `Loop`, and `If` instructions to use a `BlockType`
instead of a `ResultType`. This allows these instructions to have multiple
result values, as described in this WebAssembly proposal:
WebAssembly/spec#1145

To adapt the code on the `crucible-wasm` side, I have introduced a
`getBlockResultType` function to convert from a `BlockType` to a `ResultType`,
which is heavily inspired by a similar function in `haskell-wasm`. I have also
factored out some code shared in common between `translateFunction` and
`genInstruction`'s case for `Block` so that I do not have to conjure up a fresh
`BlockType` in `translateFunction`.

Part of #1069.

RyanGlScott added a commit that referenced this issue


          crucible-wasm: Change AnyFunc to FuncRef

e5272ae

This bumps the `haskell-wasm` submodule commit to
SPY/haskell-wasm@4fb4da0
and adjusts the code in `crucible-wasm` accordingly.

Part of #1069.

RyanGlScott added a commit that referenced this issue


          crucible-wasm: Adapt to Wasm's extend_N_S operations

515ec04

This bumps the `haskell-wasm` submodule commit to
SPY/haskell-wasm@d61926e,
which adds unary operators corresponding to the signed extension operators
added in WebAssembly/spec#1144. I have added
corresponding Crucible translations based on the WebAssembly reference
interpreter.

Part of #1069.

RyanGlScott added a commit that referenced this issue


          crucible-wasm: Adapt to Assertion gaining an extra argument

daea77b

This bumps the `haskell-wasm` submodule commit to
SPY/haskell-wasm@01e0ab8,
which gives `Assertion` an additional `Int` argument representing a line
number. We do not make use of this in `crucible-wasm`, so it is fine to ignore.

Part of #1069.

RyanGlScott added a commit that referenced this issue


          crucible-wasm: Adapt to multi-value Wasm proposal

9a5c646

This bumps the `haskell-wasm` submodule to include the changes from
SPY/haskell-wasm@b1874df
and
SPY/haskell-wasm@b816e04,
which change the `Block`, `Loop`, and `If` instructions to use a `BlockType`
instead of a `ResultType`. This allows these instructions to have multiple
result values, as described in this WebAssembly proposal:
WebAssembly/spec#1145

To adapt the code on the `crucible-wasm` side, I have introduced a
`getBlockResultType` function to convert from a `BlockType` to a `ResultType`,
which is heavily inspired by a similar function in `haskell-wasm`. I have also
factored out some code shared in common between `translateFunction` and
`genInstruction`'s case for `Block` so that I do not have to conjure up a fresh
`BlockType` in `translateFunction`.

Part of #1069.

RyanGlScott added a commit that referenced this issue


          crucible-wasm: Change AnyFunc to FuncRef

This bumps the `haskell-wasm` submodule commit to
SPY/haskell-wasm@4fb4da0
and adjusts the code in `crucible-wasm` accordingly.

Part of #1069.

RyanGlScott added a commit that referenced this issue


          crucible-wasm: Adapt to Wasm's extend_N_S operations

3df1869

This bumps the `haskell-wasm` submodule commit to
SPY/haskell-wasm@d61926e,
which adds unary operators corresponding to the signed extension operators
added in WebAssembly/spec#1144. I have added
corresponding Crucible translations based on the WebAssembly reference
interpreter.

Part of #1069.

RyanGlScott added a commit that referenced this issue


          crucible-wasm: Adapt to Assertion gaining an extra argument

7f9b505

This bumps the `haskell-wasm` submodule commit to
SPY/haskell-wasm@01e0ab8,
which gives `Assertion` an additional `Int` argument representing a line
number. We do not make use of this in `crucible-wasm`, so it is fine to ignore.

Part of #1069.

RyanGlScott added a commit that referenced this issue


          crucible-wasm: Adapt to multi-value Wasm proposal

e56dcee

This bumps the `haskell-wasm` submodule to include the changes from
SPY/haskell-wasm@b1874df
and
SPY/haskell-wasm@b816e04,
which change the `Block`, `Loop`, and `If` instructions to use a `BlockType`
instead of a `ResultType`. This allows these instructions to have multiple
result values, as described in this WebAssembly proposal:
WebAssembly/spec#1145

To adapt the code on the `crucible-wasm` side, I have introduced a
`getBlockResultType` function to convert from a `BlockType` to a `ResultType`,
which is heavily inspired by a similar function in `haskell-wasm`. I have also
factored out some code shared in common between `translateFunction` and
`genInstruction`'s case for `Block` so that I do not have to conjure up a fresh
`BlockType` in `translateFunction`.

Part of #1069.

RyanGlScott mentioned this issue

crucible-wasm: Support latest version of haskell-wasm #1072

Merged

RyanGlScott closed this as completed in #1072

RyanGlScott added a commit that referenced this issue


          Mention #1069 in the crucible-wasm CHANGELOG

bc005f7

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment