Stream: git-wasmtime

Topic: wasmtime / issue #4554 Update `Config::wasm_backtrace` in...

Wasmtime GitHub notifications bot (Jul 29 2022 at 14:14):

alexcrichton opened issue #4554:

With the reimplementation of backtraces in WebAssembly in #4431 there's a few updates to Config which I think would be good to do. For example:

• Config::wasm_backtrace shouldn't be needed any longer in theory. That being said we may wish to leave it around at least temporarily in case anyone runs into issues with fp-based unwinding.
• Emission of native debug information (e.g. .eh_frame and .xdata/.pdata) is now separable from wasm backtraces.
• Registration of .eh_frame and native information on module load time is also separable from wasm backtraces.

I think that we should deprecate Config::wasm_backtrace with a message saying "it will always be enabled in the future, if that causes issues let us know". Additionally I think we can add something like Config::native_unwind_info which defaults to true and configures whether unwinding information is generated and/or registered with the OS. I think this should still be true by default to assist features like RUST_BACKTRACE or anyone else who reads that registered information, but the documentation for this config can indicate that disabling has no impact on Wasmtime itself in terms of features and functionality provided.

Wasmtime GitHub notifications bot (Jul 29 2022 at 14:15):

alexcrichton labeled issue #4554:

With the reimplementation of backtraces in WebAssembly in #4431 there's a few updates to Config which I think would be good to do. For example:

• Config::wasm_backtrace shouldn't be needed any longer in theory. That being said we may wish to leave it around at least temporarily in case anyone runs into issues with fp-based unwinding.
• Emission of native debug information (e.g. .eh_frame and .xdata/.pdata) is now separable from wasm backtraces.
• Registration of .eh_frame and native information on module load time is also separable from wasm backtraces.

I think that we should deprecate Config::wasm_backtrace with a message saying "it will always be enabled in the future, if that causes issues let us know". Additionally I think we can add something like Config::native_unwind_info which defaults to true and configures whether unwinding information is generated and/or registered with the OS. I think this should still be true by default to assist features like RUST_BACKTRACE or anyone else who reads that registered information, but the documentation for this config can indicate that disabling has no impact on Wasmtime itself in terms of features and functionality provided.

Wasmtime GitHub notifications bot (Jul 29 2022 at 14:15):

alexcrichton commented on issue #4554:

cc @fitzgen

Wasmtime GitHub notifications bot (Aug 08 2022 at 20:54):

fitzgen closed issue #4554:

With the reimplementation of backtraces in WebAssembly in #4431 there's a few updates to Config which I think would be good to do. For example:

• Config::wasm_backtrace shouldn't be needed any longer in theory. That being said we may wish to leave it around at least temporarily in case anyone runs into issues with fp-based unwinding.
• Emission of native debug information (e.g. .eh_frame and .xdata/.pdata) is now separable from wasm backtraces.
• Registration of .eh_frame and native information on module load time is also separable from wasm backtraces.

I think that we should deprecate Config::wasm_backtrace with a message saying "it will always be enabled in the future, if that causes issues let us know". Additionally I think we can add something like Config::native_unwind_info which defaults to true and configures whether unwinding information is generated and/or registered with the OS. I think this should still be true by default to assist features like RUST_BACKTRACE or anyone else who reads that registered information, but the documentation for this config can indicate that disabling has no impact on Wasmtime itself in terms of features and functionality provided.

Last updated: Dec 13 2025 at 19:03 UTC