Wasmtime GitHub notifications bot (Oct 08 2020 at 10:57): Wasmtime GitHub notifications bot (Oct 08 2020 at 10:57):julian-seward1 labeled Issue #2281:
Currently, Cranelift (with the new backend) generates stackmaps (meaning, maps that show the ref-typeness or otherwise of each word of stack). There is one stackmap per function. The stackmaps cover the function's frame. Assuming a grow-down stack, the stack map covers the address range whose upper end is the pushed return address (or thereabouts), and extends downwards to cover all of the compiler-created temporaries, down to and including the outgoing parameter area for each call (for calls that pass args in memory).
This is unfortunately incompatible with SpiderMonkey's stackmap conventions, and complicates interworking with SpiderMonkey-compiled code. In the SM convention, each function's incoming parameter area is covered by its own stackmap (not the caller's), and the outgoing parameter area(s) are not covered by its own stackmap -- those are covered by the callee's. For one thing, this makes it easier to implement tail calls in the presence of stackmaps.
Hence this bug is a placeholder, for work on changing CL to use SpiderMonkey's conventions.
Wasmtime GitHub notifications bot (Oct 08 2020 at 10:57):julian-seward1 opened Issue #2281:
Currently, Cranelift (with the new backend) generates stackmaps (meaning, maps that show the ref-typeness or otherwise of each word of stack). There is one stackmap per function. The stackmaps cover the function's frame. Assuming a grow-down stack, the stack map covers the address range whose upper end is the pushed return address (or thereabouts), and extends downwards to cover all of the compiler-created temporaries, down to and including the outgoing parameter area for each call (for calls that pass args in memory).
This is unfortunately incompatible with SpiderMonkey's stackmap conventions, and complicates interworking with SpiderMonkey-compiled code. In the SM convention, each function's incoming parameter area is covered by its own stackmap (not the caller's), and the outgoing parameter area(s) are not covered by its own stackmap -- those are covered by the callee's. For one thing, this makes it easier to implement tail calls in the presence of stackmaps.
Hence this bug is a placeholder, for work on changing CL to use SpiderMonkey's conventions.
Wasmtime GitHub notifications bot (Oct 08 2020 at 10:57):julian-seward1 labeled Issue #2281:
Currently, Cranelift (with the new backend) generates stackmaps (meaning, maps that show the ref-typeness or otherwise of each word of stack). There is one stackmap per function. The stackmaps cover the function's frame. Assuming a grow-down stack, the stack map covers the address range whose upper end is the pushed return address (or thereabouts), and extends downwards to cover all of the compiler-created temporaries, down to and including the outgoing parameter area for each call (for calls that pass args in memory).
This is unfortunately incompatible with SpiderMonkey's stackmap conventions, and complicates interworking with SpiderMonkey-compiled code. In the SM convention, each function's incoming parameter area is covered by its own stackmap (not the caller's), and the outgoing parameter area(s) are not covered by its own stackmap -- those are covered by the callee's. For one thing, this makes it easier to implement tail calls in the presence of stackmaps.
Hence this bug is a placeholder, for work on changing CL to use SpiderMonkey's conventions.
Last updated: Dec 23 2024 at 12:05 UTC