Stream: git-wasmtime

Topic: wasmtime / issue #3277 Cranelift: Insert veneers for inte...

Wasmtime GitHub notifications bot (Sep 01 2021 at 18:23):

alexcrichton labeled issue #3277:

More details coming soon, reserving an issue number to write in the code...

Wasmtime GitHub notifications bot (Sep 01 2021 at 18:23):

alexcrichton labeled issue #3277:

More details coming soon, reserving an issue number to write in the code...

Wasmtime GitHub notifications bot (Sep 01 2021 at 18:23):

alexcrichton opened issue #3277:

More details coming soon, reserving an issue number to write in the code...

Wasmtime GitHub notifications bot (Sep 01 2021 at 18:23):

alexcrichton labeled issue #3277:

More details coming soon, reserving an issue number to write in the code...

Wasmtime GitHub notifications bot (Sep 01 2021 at 18:31):

alexcrichton edited issue #3277:

This issue is intended to track this FIXME in the code which specifically relates to how inter-function relative calls, used for the first time in Wasmtime in https://github.com/bytecodealliance/wasmtime/pull/3275, have limited jump ranges (especially on AArch64 with 26-bit jumps), and may need fixups.

Today if a compiled function on AArch64 is greater than 64MB in size then it runs the risk of panicking when "linking" if it needs to call a function defined after that function. The MachBuffer used when assembling the function does not keep track of relative calls and where they are, instead it just assumes all relocations will still work once the function is fully generated.

The fix for this issue will be introducing the notion of a permanently unresolved label in MachBuffer. This label would then be used for relocations which are recognized as a LabelUse (probably via the LabelUse::from_reloc function). The MachBuffer would automatically insert veneers for these LabelUse items and, at the end of a function, would take all the remaining LabelUse items and generate relocations for them.

Last updated: Nov 22 2024 at 17:03 UTC