Stream: git-wasmtime

Topic: wasmtime / issue #4298 Investigate storing trap codes in ...


view this post on Zulip Wasmtime GitHub notifications bot (Jun 22 2022 at 20:06):

alexcrichton opened issue #4298:

https://github.com/bytecodealliance/wasmtime/issues/3340, specifically this:

Note that UDF has an immediate parameter, which could be used to address the second point to an extent, e.g. UDF #0xBAD could signify Cranelift-generated code.

got me wondering if we can store the .wasmtime.traps section directly in the text section instead of in a separate section of the executable. As a separate section this is somewhat hefty and would probably be much smaller if we simply stored the trap code in the instruction itself (like #0xBAD above).

I'm not sure if this is possible on all platforms though or whether it's even going to net us all that many savings. Not having to manage a side table of traps though would indeed simplify a number of pieces related to trap handling in Wasmtime.

view this post on Zulip Wasmtime GitHub notifications bot (Jun 22 2022 at 20:06):

alexcrichton labeled issue #4298:

https://github.com/bytecodealliance/wasmtime/issues/3340, specifically this:

Note that UDF has an immediate parameter, which could be used to address the second point to an extent, e.g. UDF #0xBAD could signify Cranelift-generated code.

got me wondering if we can store the .wasmtime.traps section directly in the text section instead of in a separate section of the executable. As a separate section this is somewhat hefty and would probably be much smaller if we simply stored the trap code in the instruction itself (like #0xBAD above).

I'm not sure if this is possible on all platforms though or whether it's even going to net us all that many savings. Not having to manage a side table of traps though would indeed simplify a number of pieces related to trap handling in Wasmtime.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 31 2022 at 05:45):

yuyang-ok commented on issue #4298:

I think it is fine to save trap_code after udf on riscv.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 31 2022 at 05:59):

yuyang-ok deleted a comment on issue #4298:

I think it is fine to save trap_code after udf on riscv.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 31 2022 at 07:30):

yuyang-ok commented on issue #4298:

I think a explicit udf ... can store trap code in .text, but a load can cause HeapOutOFBounds trap and there is no place to save trap_code.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 31 2022 at 07:57):

yuyang-ok edited a comment on issue #4298:

I think a explicit udf ... can store trap code in .text, but a load may cause HeapOutOFBounds trap and there is no place to save trap_code.

view this post on Zulip Wasmtime GitHub notifications bot (Aug 31 2022 at 08:14):

yuyang-ok edited a comment on issue #4298:

I think a explicit udf ... can store trap code in .text, but a load may cause HeapOutOFBounds trap and there is no place to save trap_code.
I mean udf always cause trap can store trap_code after udf.
load may trap maybe have to emit a jump jumpover trap_code , this is a little wired.


Last updated: Oct 23 2024 at 20:03 UTC