Open PanayotCankov opened 9 years ago
jasssonpet
commented
9 years ago We should generate trampolines for:
fealebenpae
commented
9 years ago We don't have a way to create function pointer callbacks with the restrictions placed on us by bitcode.
jeduden
commented
7 years ago @fealebenpae, @jasssonpet do you have more details why function pointer callbacks can't be generated ?
TheFonz2017
commented
6 years ago Hey there, just wondering, what the status of this is, as I saw it being set in progress and then set on hold again. Is this something you guys are still actively working on? And is there a chance we will see this live anytime soon? I am afraid this will become a major issue for all apps using NativeScript once Apple makes bitcode mandatory in the App Store (which I believe they plan on doing). Thanks!
SplinterStan
commented
5 years ago I am afraid this will become a major issue for all apps using NativeScript once Apple makes bitcode mandatory in the App Store (which I believe they plan on doing).
I agree, our clients are requiring bitcode support for security checks of our app, so we're already suffering đ˘ Would be great, if you guys could proceed working on this đ
mbektchiev
commented
5 years ago @SplinterStan Unfortunately this is not easily achievable for the current version of the iOS runtime. We've tried enabling it earlier but we faced issues with the build toolchain which prevented us from compiling our custom version of JSC with BITCODE enabled. After reporting them to Apple they unofficially told us that we shouldn't be concerned too much as BITCODE is not expected to become mandatory anytime soon (this was around WWDC 2018 so we can't know for sure if anything has changed in their plans but still we haven't found any statements so far that may suggest the opposite).
Having said that, we've recently launched an alpha version of the iOS Runtime which is powered by the V8 engine and with it, we no longer face these limitations. Actually, we've tested that the runtime can be built with BITCODE switched ON. However, we are still far from releasing it officially and I can't tell you either when it will be ready, nor when we'll enable BITCODE in it.
If you feel curious to know if your app will work with it, you can try it with tns platform add ios@alpha-v8 but have in mind that it currently doesn't have BITCODE.
SplinterStan
commented
5 years ago @mbektchiev Thank you for your reply. I appreciate that you take time trying to add BITCODE support đ . Cool, I will try out the mentioned runtime and give you a shout whether its working. For us it's just important to deliver versions that are compiled according to security software guidelines (e.g. Veracode) in order to pass the security check.
iOS 9 Introduced Bitcode Submission
We should be able to submit NativeScript for iOS apps built for Bitcode. At the moment this is mandatory for WatchOS, and enabled by default for Apple's App Store submissions.
One of the main problems is Bitcode can not include inline assembly.
FFI
Our current machinery implements calls and callbacks to and from Objective-C methods and C functions using FFI. FFI however uses some internal mechanics that rely on inline assembly. As such we should drop the FFI from the runtime. However to perform well and keep the runtime app size and memory footprint small we need a proper substitute for the FFI calls and callbacks. This naturally evolves in "trampolines" generated at compile time.
Our current vision for the trampolines have 2 forms
objc_msgSend*and the family, literally replacing the current function factory provided by the FFI API with similar that will use compile time generated functions.objc_msgSend*and the family but also handle the marshalling. Since we will be generating code we can make the calls accept ExecState and handle internally the marshalling, skipping the current read/write/preCall/postCall infrastructure and stack allocation.These are some suggested steps that will lead us in that direction. However we are agile and they will be further discussed:
This will help us match calls with a trampoline generated at build time. It should still contain precise information and be used for marshalling. It should be easily mapped to a low-level signature:
It should be identified by type (function, method, block) and its signature. It will be used as a hash used to lookup a trampoline at runtime. Effectively two high-level signatures can differ but have the same low-level signature. Low-level signatures will treat all pointer types simply as pointer. (e.g. it won't matter if it is UIButton* or UIView* it will still be a *) It would be used with ffi-like APIs.
Since the trampoline functions can generate large binary, we may have to cut them in size by doing an API usage analysis on the JavaScript files. (Something similar is already in place for the android runtime) The tool should report which functions and methods are used. It will probably be chained after our metadata generator tool. The information from the API usage tool and the type information provided by the metadata generator should be combined and provided as input for the next.
It should either write plain text C or it can use the LLVM compiler. We should check if the bitcode generated by LLVM is compatible with the Bitcode used for app submissions. Either way these trampolines will be functions that will be used to replace the functions generated by FFI.
At some point when this process is stable we should start integrating the generate trampolines and obsolete the FFI. The overall process should enforce changes in the runtime. We should add some code that queries trampolines based on their signature and integrate it in the FFICall and FFICallback classes.
JavaScriptCore Bitcode build.
We will have to strip the inline assembly from our version of JavaScriptCore. Some progress in that direction is done by @fealebenpae and @jasssonpet for the WinRT bridge based on JavaScriptCore so the task appears feasible for the moment.
Builds