Revive support for interpreting code in Flutter debug builds on iOS

[a-siva]

Starting with iOS 18.4 an app can no longer write into its own executable memory and flip permission RX->RW and back as a result of this we need to revive support for interpreting code in Flutter debug builds on iOS.

Issues that need resolution

• support for interpreting code in Flutter debug builds
• support for dart:ffi in the above mode
• address potential performance degradation that could result from interpreting byte codes.

[a-siva]

//cc @rmacnak-google @alexmarkov @mkustermann @mraleph @dcharkes

[a-siva]

Possible options to evaluate

• use simarm64
• revive DBC (Dart byte codes)

[a-siva]

Here are the list of actions items

• Wire up flutter tools to add a new configuration debug / simarm64 which would be used on iOS (Add support for debug/simarm64 configuration in Flutter tools flutter/flutter#164045)
• Get dart:ffi to work with simarm64 configuration (ensure vm_remap continues to work) [vm/ffi] Support FFI on simarm64 #60204
• Explore alternative ideas for interpreting code in a more optimal manner than by using simarm64 (Explore alternative ideas for interpreting code in a more optimal manner than by using simarm64 #60205)

[jtmcdole]

Drive-by thought: Long term, would it be wise to invest in WASM for these cases?

[mraleph]

@jtmcdole

Drive-by thought: Long term, would it be wise to invest in WASM for these cases?

How do you think Wasm helps here?

[a-siva]

Dropping priority to P2, @mraleph has landed a solution using lldb which appears to work.

[JJTech0130]

Apple appears to have walked back this restriction in 18.4 beta 2. We'll see if it stays that way.

...if Apple changes their mind again, either all memory writes can be redirected through lldb, or the memory can be remapped using the debugger in such a way that you have access to both a writable and executable view of the same memory: https://gist.github.com/JJTech0130/142aee0f7bda9c61a421140d17afbdeb