Conversation
EABI_APPLE, ARMv7s, configurable support for PIE. PIC is now on if supported for the model.
This also includes: - workaround for the generation of jump tables in thumb mode - workaround for the generation of frametables - basic changes in arm.S - introduction of ldgaddr and ldladdr macros in arm.S which will be exploited later in the PIE patch - a little EABI fixup in arm.S: saving all FP regs where needed (EABI_APPLE is an EABI_HF variant)
- on ARMv7s there are machine instructions
- IOS defines __divsi3 and __modsi3 instead of __aeabi_idiv and
__aeabi_imod, resp
The apple assembler does not understand some of pre-UAL mnemonics
This is a little bit tricky, as these conventions do not directly fit to the framework (which doesn't support register pairs). The workaround is that we pretend that the first two float args are passed via d0 and d1, and that the single float result comes back in d0. This is not the truth, but fits into the framework. In reality, the float args go into r0/r1, r1/r2 or r2/r3, and are mixed with any int or pointer args. The float result is in r0/r1. When we emit the call instruction, we also emit additional code that moves the floats from d0 and d1 to the register pairs (and potentially also moves the integers away that are already there). After returning from the call, the float, if any, is loaded into d0. The price of this workaround: up to three additional moves per extcall.
This only affects symbol literals. Jumps can be resolved by ld (that's where PIE is simpler than PIC).
Only for add/sub we can handle negative immediates by inverting the operation. (This is for all platforms, not only iOS.)
- index immediates need a hash mark according to ARM - avoiding multi-statement C macros and using assembler macros instead
These instructions do not support an immediate arg of #0 in thumb mode. Replacing by a simple mov.
|
How does this relate to GPR #182, actually?
|
|
GPR #182 is what I referred to as "Psellos patchset". |
|
whitequark (2017/03/06 00:57 -0800):
GPR #182 is what I referred to as "Psellos patchset".
OK, sorry!
|
|
At first glance, it seems to me this PR does not include everything that
was included in PR#182, e.g. am I correct that commit
a755f51 has not been included in this
PR?
|
Yes. I did not alter the build system in any way because my method for producing cross-compilers is more robust, more flexible and doesn't need any build system hacks anyway. It is only my goal here to make OCaml mainline compatible with opam-cross-ios, just like the existing Android support is compatible with opam-cross-android; in neither case the configure script is helpful. |
|
One random remark: there are some changes relating to assembler directives which have to differ on various platforms. We should merge such changes into #756 , which is designed to abstract away from such things. |
|
@mshinwell I'm fine with waiting until #756 lands. |
|
In your opam installation, you apply this patch. Should it be included in this PR? |
This was originally done in 5d02ca6, but subsequently clobbered while adding the iOS port.
|
Can this PR be re-rebased against trunk and if changes are not too significant maybe I could help with that in some way? It looks like improved native debugger support is taking longer than originally planned, so maybe this could be merged in? |
|
I managed to cherry-pick these commits on top of Whether it's correct is entirely different matter, but my question is where do I go from there? |
|
Hi, Rauan,
Not sure the PR can be rebased right now, unless somebody volunteers to
do so.
Re:cross compiling for iOS, could we please exchange privately?
Would you please be kind enough and e-mail me at
[email protected] regarding this?
Many thanks in advance!
|
|
Rauan Mayemir (2019/01/17 09:20 +0000):
I managed to cherry-pick these commits on top of `4.07` branch and resolve the conflicts: https://github.com/esy-cross/ocaml/tree/4.07+ios.
Whether it's correct is entirely different matter, but my question is
where do I go from there? `ocaml-cross` had extra configs to inject
the correct toolchain and vars, this one doesn't.
I think Gerd Stolpmann and/or Jeffrey Scofield (@jeffsco)
could help. I couldn't ifnd Gerd's GitHub user name, unfortunately.
In case you contact them by e-mail, could you please include me in the
discussion?
|
|
I had funded whitequark's effort to create opam-cross-ios. Last year, I brought opam-cross-ios up to 4.07.0 last year. It can be found here: This is currently be used in large production software running 64-bit on IOS. I believe the 32-bit fixes were complete as well, but I don't think 32-bit is no longer relevant on IOS. If you have any questions about the patch, please feel free to contact me. |
|
@markghayden This is wonderful! How did you make the config scripts for building to work? I.e Makefile.in files from opam-cross.package. |
I looked at every #define, etc that OCaml needs and manually filled it in with the correct value for iOS. |
|
Hey @whitequark, thanks for popping in! I meant for 4.07 to work. I tried to follow your steps and make it work for version 4.07, but kept having '../boot/ocamlc is not a bytecode executable file'. I now suspect that I may have messed something up resolving git conflicts in mlp files. I'll try this again with Mark's fork. |
|
Mark Hayden (2019/05/05 19:35 -0700):
I had funded whitequark's effort to create opam-cross-ios.
Last year, I brought opam-cross-ios up to 4.07.0 last year.
It can be found here:
https://github.com/markghayden/ocaml/tree/4.07.0%2Bios
Thanks a lot. Does it use the `-with-target-bindir` configure option?
Do you have the project ot make it work with 4.08, too?
This is currently be used in large production software running 64-bit
on IOS. I believe the 32-bit fixes were complete as well, but I don't
think 32-bit is no longer relevant on IOS. If you have any questions
about the patch, please feel free to contact me.
I'd be very interested in learning more about this: the kind of
applications this makes possible, how they are actually deployed on iOS
devices and whether they have a graphical interface or not.
|
I'm not sure about -with-target-bindir. Please note that my work was based on Whitequark's patch who deserves 100% credit and upgrading to 4.07 was done as minimum change to his work.
Sure; please see http://seaiq.com. This is marine navigation software used by pilot to bring ships in/out of ports. Like google maps for large ships. It has a graphical interface (OpenGL/ES). There is a free evaluation download and screenshots/videos on the web site. The apps are deployed to IOS devices via the Apple app store, similar to other apps. The Ocaml code is wrappered in a C API and then accessed on IOS via Objective C code (no Swift, which the software predated). |
|
Mark Hayden (2019/05/17 16:13 -0700):
I'm not sure about -with-target-bindir. Please note that my work was
based on Whitequark's patch who deserves 100% credit and upgrading to
4.07 was done as minimum change to his work.
Will look into it, thank!
> I'd be very interested in learning more about this: the kind of applications this makes possible, how they are actually deployed on iOS devices and whether they have a graphical interface or not.
Sure; please see http://seaiq.com. This is marine navigation software
used by pilot to bring ships in/out of ports. Like google maps for
large ships. It has a graphical interface (OpenGL/ES). There is a
free evaluation download and screenshots/videos on the web site. The
apps are deployed to IOS devices via the Apple app store, similar to
other apps. The Ocaml code is wrappered in a C API and then accessed
on IOS via Objective C code (no Swift, which the software predated).
OK so does this mean that all the graphical part is done by Objective-C
code, or do you have a way to access OpenG from OCaml?
|
|
The graphics is done by OpenGL calls made from ML through the LabelGL or LableGLES libraries. At some point, I’ve been planning to change to TGLS.
The high level window setup is done in Objective C using GLKView. On other platforms, I use Qt library for windows and GUI.
… On May 21, 2019, at 5:48 AM, Sébastien Hinderer ***@***.***> wrote:
Mark Hayden (2019/05/17 16:13 -0700):
> I'm not sure about -with-target-bindir. Please note that my work was
> based on Whitequark's patch who deserves 100% credit and upgrading to
> 4.07 was done as minimum change to his work.
Will look into it, thank!
> > I'd be very interested in learning more about this: the kind of applications this makes possible, how they are actually deployed on iOS devices and whether they have a graphical interface or not.
>
> Sure; please see http://seaiq.com. This is marine navigation software
> used by pilot to bring ships in/out of ports. Like google maps for
> large ships. It has a graphical interface (OpenGL/ES). There is a
> free evaluation download and screenshots/videos on the web site. The
> apps are deployed to IOS devices via the Apple app store, similar to
> other apps. The Ocaml code is wrappered in a C API and then accessed
> on IOS via Objective C code (no Swift, which the software predated).
OK so does this mean that all the graphical part is done by Objective-C
code, or do you have a way to access OpenG from OCaml?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#1084?email_source=notifications&email_token=ABCEANT6NEHJQ72MBV2UKXDPWPAP3A5CNFSM4DCPMU62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODV3L6RA#issuecomment-494321476>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABCEANT4P2FDM7LPOQVY2XDPWPAP3ANCNFSM4DCPMU6Q>.
|
|
Thanks a lot, Mark!
So, you never have to interact with Apple libraries for the graphical
things?
|
|
No, other than high-level setup for the drawing area. For instance, fonts are drawn directly from ML using textures and the Freetype library.
—Mark
… On May 21, 2019, at 8:19 AM, Sébastien Hinderer ***@***.***> wrote:
Thanks a lot, Mark!
So, you never have to interact with Apple libraries for the graphical
things?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#1084?email_source=notifications&email_token=ABCEANXJ5YHTKX3ZPZMSRN3PWPSFTA5CNFSM4DCPMU62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODV3XDUQ#issuecomment-494367186>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABCEANU7T5XVFXAB4LLJ6ZLPWPSFTANCNFSM4DCPMU6Q>.
|
|
As a lighter (and faster) alternative would be to use OCaml-Vulkan + MoltenVK. |
|
That is a great idea and may be the route we take when OpenGLES2 is deprecated on IOS.
Right now, I think the performance of LablGL is adequate for us and the biggest concern is around compatibility since our GL drawing needs to run on IOS, Android, Windows, and MacOS.
—Mark
… On May 21, 2019, at 8:54 AM, Anton Kochkov ***@***.***> wrote:
As a lighter (and faster) alternative would be to use OCaml-Vulkan <https://github.com/Octachron/olivine> + MoltenVK <https://github.com/KhronosGroup/MoltenVK>.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#1084?email_source=notifications&email_token=ABCEANVCPRT2TWORDBR2JB3PWPWI5A5CNFSM4DCPMU62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODV3Z5KQ#issuecomment-494378666>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABCEANVMHPGI7CUMIKRVSU3PWPWI5ANCNFSM4DCPMU6Q>.
|
|
@markghayden Does your 4.07.0+ios branch integrate with opam-cross-ios? How do you configure the build for a cross compiler? |
|
Yes, we build everything as part of opam-cross-ios. I have a fork of that project on github: https://github.com/markghayden/opam-cross-ios
—Mark
… On Jun 22, 2019, at 8:53 PM, Boris D. ***@***.***> wrote:
@markghayden <https://github.com/markghayden> Does your 4.07.0+ios branch integrate with opam-cross-ios? How do you configure the build for a cross compiler?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#1084?email_source=notifications&email_token=ABCEANSNUOYA6LRS35CUDIDP33QRTA5CNFSM4DCPMU62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYKVMRY#issuecomment-504714823>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABCEANV2RCFEGALPNRAQO2LP33QRTANCNFSM4DCPMU6Q>.
|
|
@markghayden Great. Thanks. |
|
Hi Boris,
I edited the Xcode system header file, as an interim solution. This should probably fixed as part of s.h file.
—Mark
… On Jun 22, 2019, at 10:21 PM, Boris D. ***@***.***> wrote:
@markghayden <https://github.com/markghayden> Great. Thanks.
How do you deal with the following issue? Which version of Xcode works for you?
#=== ERROR while compiling ocaml-ios64.4.07.0 =================================#
# context 2.0.4 | macos/x86_64 | ocaml-base-compiler.4.07.0 | git+file:///Volumes/Mojave/Users/boris/src/ocaml/cross/opam-cross-ios
# path ~/.opam/4.07.0/.opam-switch/build/ocaml-ios64.4.07.0
# command ~/.opam/opam-init/hooks/sandbox.sh build make -j4 world
# exit-code 2
# env-file ~/.opam/log/ocaml-ios64-24995-90b366.env
# output-file ~/.opam/log/ocaml-ios64-24995-90b366.out
### output ###
# [...]
# #define CAML_SYS_SYSTEM(command) system_os(command)
# ^
# ./caml/misc.h:215:19: note: expanded from macro 'system_os'
# #define system_os system
# ^
# /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS11.4.sdk/usr/include/stdlib.h:195:6: note: 'system' has been explicitly marked unavailable here
# int system(const char *) __DARWIN_ALIAS_C(system);
# ^
# 1 error generated.
# make[1]: *** [sys.o] Error 1
# make[1]: *** Waiting for unfinished jobs....
# make: *** [coldstart] Error 2
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#1084?email_source=notifications&email_token=ABCEANTLNTQDPOHAXRPCDQ3P3325TA5CNFSM4DCPMU62YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODYKWJNI#issuecomment-504718517>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABCEANQBOFNJBEY27WXTVALP3325TANCNFSM4DCPMU6Q>.
|
|
Would be nice to rebase and reevaluate against 4.09 to target 4.10 if possible. |
|
Anton Kochkov (2019/09/20 00:39 -0700):
Would be nice to rebase and reevaluate against 4.09 to target 4.10 if
possible.
Well I'm supposed to make the build system evolve to make it easier to
build cross-compilers in general first so I'm not sure how urgent this
rebase is. It seems too late for 4.10 anyway, frankly speaking, because
AFAIK the feature freeze is supposed to happen in less than a month.
|
|
I would like to push this PR forward or open a new one if needed, perhaps it's possible to even get it for the next version, also it's possible to try to run the test suite on a jailbroken iPhone or on the iOS ARM emulator. I rebased it to 4.08 and did some changes, so it's mostly this commit, there is also some unrelated changes on this branch and it still has some cleanup, but it's working. Removed support to arm32Even Apple seems to not support it anymore, and the last iPhone running 32bits is the iPhone 5c which is stuck on iOS 10 Use C macrosTo clean up the patch, instead of using apple |
|
This can be closed I suppose. |
13 participants
This is a cleaned-up Psellos patchset that I've rebased on top of 4.04 and now trunk (there weren't any conflicts when moving between 4.04 and trunk). It's been used in production for quite some time.
The PR is not as clean as it perhaps should be, commit messages and all, but I would like to get some initial feedback before spending more time on this.