New arm64_32 architecture (watchOS 5) #10641

marek-safar · 2018-09-17T10:36:03Z

This is tracking task to collect information about arm64_32 architecture and what will be needed to support it.

It was introduced with Xcode 10 GM but there is no documentation yet. Example of disassembled code https://gist.github.com/rolfbjarne/24465d3fd9ff53e1a8919b7ea602d976

ILP32 Whitepaper

Milestone I (2018-10)

Release mode support (llvm_only/bitcode). This is done using the the AOT compiler for armv7k (the old watch) and let LLVM take care to generate correct code for arm64_32.

Milestone II (2019-08)

Debug mode support for arm64_32 backend. This requires changes in our arm64 backend to be aware of arm64_32. It's needed because our managed debugger doesn't work with LLVM generated code.
~~Extend iOS SDK such that we can use it for watchOS too. This allows use to develop arm64_32 related changes outside of Xamarin.iOS.~~

The text was updated successfully, but these errors were encountered:

lewurm · 2018-10-02T08:05:37Z

As a note: While it's tempting to ignore this in mono and use bitcode-build-tool as described here https://mobile.twitter.com/jckarter/status/1044719452418322432 it unfortunately isn't a long-term solution for us:

Apple requires arm64_32 bitcode in March next year
Xcode 10 already requires that (you can hack around it by using Xcode 9.4 for now )
debugging doesn't work
build time would be even slower with bitcode-build-tool

source: https://xamarinhq.slack.com/archives/C03CELHQQ/p1538456914000100

/cc @rolfbjarne

lewurm · 2018-11-15T01:29:14Z

Using this comment to track related PRs (in case we need to backport changes at some point).

Release mode:

Debug mode:

rolfbjarne · 2019-08-26T10:22:55Z

@marek-safar the Debug mode support for arm64_32 backend task clearly didn't make 2019-04, do you have an updated milestone for that task?

lewurm · 2019-08-26T11:51:31Z

@rolfbjarne that's my fault, I abandoned that work unintentionally and never got back to it. Sorry about that. I do have some patches that make Debug mode work with the interpreter, that might be worthwhile enough. We can then evaluate if we need to make AOT work as well.

Will do it this or next sprint, so it should be 2019-08.

#16865) [arm64_32] make "Debug Mode" work on Watch series 4 with --interpreter Main objective for reviewers: This PR shouldn't change anything for `arm64`. Context: "Debug Mode" on the Apple Watch allows execution of regular machine code and thus is pretty similar to FullAOT on iPhone, i.e. it doesn't require bitcode, but _still_ doesn't allow `signal(3)` so cooperative suspend is required. Apple Watch Series 4 and onward use an ARM64 chip, but with a different ABI, also known as `arm64_32`. This PR changes the AOT compiler and related trampolines so that the AOT compiler can generate all necessary code to run the interpreter on this target. Changes: -------------------------------------- [arm64_32] set register size to 8 in cross compiler too ----------------------------------------- [machine] update `target_mgreg_t` definition `SIZEOF_REGISTER` is usually the same as `TARGET_SIZEOF_VOID_P`, except when `MONO_ARCH_ILP32 is defined. `target_mgreg_t` should represent the width of the hardware register, that is, `SIZEOF_REGISTER`. --------------------------------------------- [arm64_32] fix AOT image layout --------------------------------------------- [arm64_32] make trampolines bitwidth aware * replace pointer loads/stores with bitwidth-dependent macro * reflect `specific` trampolines so that only two instructions are used for ILP32, since the related pair in the data page only needs 2 * 32bits too * replace some `sizeof (target_mgreg_t)` with `TARGET_SIZEOF_VOID_P` (former is hardware register size, latter is pointer size) --------------------------------------------- These regression tests are _not_ passing: #16864 Also some of monotouch-tests are crashing, see #16819 Here is a screenshot of a debug session in VSMac: <img width="1321" alt="Screenshot 2019-09-16 at 19 13 22" src="https://user-images.githubusercontent.com/75403/64981326-1dfbc000-d8bc-11e9-9d16-48036f36b638.png"> Contributes to #10641

@lewurm

…interpreter (#16886) [2019-08] [arm64_32] make "Debug Mode" work on Watch series 4 with --interpreter Main objective for reviewers: This PR shouldn't change anything for `arm64`. Context: "Debug Mode" on the Apple Watch allows execution of regular machine code and thus is pretty similar to FullAOT on iPhone, i.e. it doesn't require bitcode, but _still_ doesn't allow `signal(3)` so cooperative suspend is required. Apple Watch Series 4 and onward use an ARM64 chip, but with a different ABI, also known as `arm64_32`. This PR changes the AOT compiler and related trampolines so that the AOT compiler can generate all necessary code to run the interpreter on this target. Changes: -------------------------------------- [arm64_32] set register size to 8 in cross compiler too ----------------------------------------- [machine] update `target_mgreg_t` definition `SIZEOF_REGISTER` is usually the same as `TARGET_SIZEOF_VOID_P`, except when `MONO_ARCH_ILP32 is defined. `target_mgreg_t` should represent the width of the hardware register, that is, `SIZEOF_REGISTER`. --------------------------------------------- [arm64_32] fix AOT image layout --------------------------------------------- [arm64_32] make trampolines bitwidth aware * replace pointer loads/stores with bitwidth-dependent macro * reflect `specific` trampolines so that only two instructions are used for ILP32, since the related pair in the data page only needs 2 * 32bits too * replace some `sizeof (target_mgreg_t)` with `TARGET_SIZEOF_VOID_P` (former is hardware register size, latter is pointer size) --------------------------------------------- These regression tests are _not_ passing: #16864 Also some of monotouch-tests are crashing, see #16819 Here is a screenshot of a debug session in VSMac: <img width="1321" alt="Screenshot 2019-09-16 at 19 13 22" src="https://user-images.githubusercontent.com/75403/64981326-1dfbc000-d8bc-11e9-9d16-48036f36b638.png"> Contributes to #10641 Backport of #16865. /cc @lewurm

lewurm · 2019-09-24T13:32:31Z

Related changes have been landed into 2019-08.

For the sake of referencing: #16864 and xamarin/xamarin-macios#7076

@lambdageek

#17015) [2019-08] [threads] clear small_id_key TLS when unregistering a thread Fixes ``` * thread #12, name = 'tid_a507', stop reason = EXC_BREAKPOINT (code=1, subcode=0x1be66144) * frame #0: 0x1be66144 libsystem_c.dylib`__abort + 184 frame #1: 0x1be6608c libsystem_c.dylib`abort + 152 frame #2: 0x003e1fa0 monotouchtest`log_callback(log_domain=0x00000000, log_level="error", message="* Assertion at ../../../../../mono/utils/hazard-pointer.c:158, condition `mono_bitset_test_fast (small_id_table, id)' not met\n", fatal=4, user_data=0x00000000) at runtime.m:1251:3 frame #3: 0x003abf44 monotouchtest`monoeg_g_logv_nofree(log_domain=0x00000000, log_level=G_LOG_LEVEL_ERROR, format=<unavailable>, args=<unavailable>) at goutput.c:149:2 [opt] frame #4: 0x003abfb4 monotouchtest`monoeg_assertion_message(format=<unavailable>) at goutput.c:184:22 [opt] frame #5: 0x003904dc monotouchtest`mono_thread_small_id_free(id=<unavailable>) at hazard-pointer.c:0:2 [opt] frame #6: 0x003a0a74 monotouchtest`unregister_thread(arg=0x15c88400) at mono-threads.c:588:2 [opt] frame #7: 0x00336110 monotouchtest`mono_thread_detach_if_exiting at threads.c:1571:4 [opt] frame #8: 0x003e7a14 monotouchtest`::xamarin_release_trampoline(self=0x166452f0, sel="release") at trampolines.m:644:3 frame #9: 0x001cdc40 monotouchtest`::-[__Xamarin_NSTimerActionDispatcher release](self=0x166452f0, _cmd="release") at registrar.m:83445:3 frame #10: 0x1ce2ae68 Foundation`_timerRelease + 80 frame #11: 0x1c31b56c CoreFoundation`CFRunLoopTimerInvalidate + 612 frame #12: 0x1c31a554 CoreFoundation`__CFRunLoopTimerDeallocate + 32 frame #13: 0x1c31dde4 CoreFoundation`_CFRelease + 220 frame #14: 0x1c2be6e8 CoreFoundation`__CFArrayReleaseValues + 500 frame #15: 0x1c2be4c4 CoreFoundation`CFArrayRemoveAllValues + 104 frame #16: 0x1c31ff64 CoreFoundation`__CFSetApplyFunction_block_invoke + 24 frame #17: 0x1c3b2e18 CoreFoundation`CFBasicHashApply + 116 frame #18: 0x1c31ff10 CoreFoundation`CFSetApplyFunction + 160 frame #19: 0x1c3152cc CoreFoundation`__CFRunLoopDeallocate + 204 frame #20: 0x1c31dde4 CoreFoundation`_CFRelease + 220 frame #21: 0x1c304a80 CoreFoundation`__CFTSDFinalize + 144 frame #22: 0x1bfa324c libsystem_pthread.dylib`_pthread_tsd_cleanup + 644 frame #23: 0x1bf9cc08 libsystem_pthread.dylib`_pthread_exit + 80 frame #24: 0x1bf9af24 libsystem_pthread.dylib`pthread_exit + 36 frame #25: 0x0039df84 monotouchtest`mono_threads_platform_exit(exit_code=<unavailable>) at mono-threads-posix.c:145:2 [opt] frame #26: 0x0033bb84 monotouchtest`start_wrapper(data=0x1609e1c0) at threads.c:1296:2 [opt] frame #27: 0x1bf9b914 libsystem_pthread.dylib`_pthread_body + 128 frame #28: 0x1bf9b874 libsystem_pthread.dylib`_pthread_start + 44 frame #29: 0x1bfa3b94 libsystem_pthread.dylib`thread_start + 4 ``` Debugged by @lambdageek. Contributes to #10641 Edit: C/p into PR description so it's in the commit message: We think what happens is: 1. `start_wrapper` runs `unregister_thread` when the thread is exiting. At that point the `small_id` for the thread is cleared from the hazard pointer bitset by `mono_thread_small_id_free (small_id)` 2. Some other TLS destructor runs and attaches the thread again (which runs `mono_thread_info_register_small_id` which first calls `mono_thread_info_get_small_id` which tries to get the small id from the `small_id_key` TLS key and so the new `MonoThreadInfo` has the same `small_id` as the previously destroyed `MonoThreadInfo` - but the hazard pointer bitset is **not** updated). 3. This other TLS destructor runs and calls `mono_thread_detach_if_exiting` which calls `unregister_thread` again. 4. `unregister_thread` calls ` mono_thread_small_id_free (small_id)` a second time which asserts because we already cleared that id from the hazard pointer bitset. Backport of #16973. /cc @lewurm

onurhazar · 2019-11-08T14:07:03Z

@lewurm
I am using the latest version of Xamarin.iOS (13.6.0.12) but it says
MTOUCH: Error MT0014: The iOS 6.1 SDK does not support building applications targeting x86_64 (MT0014)
Deploying and debugging to simulator also doesn't work.

lewurm · 2019-11-09T15:05:30Z

@onurhazar what exactly are you trying to do? There is something weird, because the log says targeting x86_64 which isn't a target available for watchOS (neither on devices and simulators; it's i386, armv7k or arm64_32).

/cc @rolfbjarne

rolfbjarne · 2019-11-11T06:09:18Z

@onurhazar as @lewurm says, there's something weird going on. Can you file a new bug with a diagnostic build log?

onurhazar · 2019-12-20T15:45:28Z

@onurhazar what exactly are you trying to do? There is something weird, because the log says targeting x86_64 which isn't a target available for watchOS (neither on devices and simulators; it's i386, armv7k or arm64_32).

/cc @rolfbjarne

Hi, I am not able to debug on the latest watch series 5 and even in simulator. I am talking about for simulator in watchos extension project / supported architecture setting; it has 3 options i386, x86_64 and both but I can't get it work with neither of them. Xamarin iOS version is 13.6.0.12.

mono/mono#16865) [arm64_32] make "Debug Mode" work on Watch series 4 with --interpreter Main objective for reviewers: This PR shouldn't change anything for `arm64`. Context: "Debug Mode" on the Apple Watch allows execution of regular machine code and thus is pretty similar to FullAOT on iPhone, i.e. it doesn't require bitcode, but _still_ doesn't allow `signal(3)` so cooperative suspend is required. Apple Watch Series 4 and onward use an ARM64 chip, but with a different ABI, also known as `arm64_32`. This PR changes the AOT compiler and related trampolines so that the AOT compiler can generate all necessary code to run the interpreter on this target. Changes: -------------------------------------- [arm64_32] set register size to 8 in cross compiler too ----------------------------------------- [machine] update `target_mgreg_t` definition `SIZEOF_REGISTER` is usually the same as `TARGET_SIZEOF_VOID_P`, except when `MONO_ARCH_ILP32 is defined. `target_mgreg_t` should represent the width of the hardware register, that is, `SIZEOF_REGISTER`. --------------------------------------------- [arm64_32] fix AOT image layout --------------------------------------------- [arm64_32] make trampolines bitwidth aware * replace pointer loads/stores with bitwidth-dependent macro * reflect `specific` trampolines so that only two instructions are used for ILP32, since the related pair in the data page only needs 2 * 32bits too * replace some `sizeof (target_mgreg_t)` with `TARGET_SIZEOF_VOID_P` (former is hardware register size, latter is pointer size) --------------------------------------------- These regression tests are _not_ passing: mono/mono#16864 Also some of monotouch-tests are crashing, see mono/mono#16819 Here is a screenshot of a debug session in VSMac: <img width="1321" alt="Screenshot 2019-09-16 at 19 13 22" src="https://user-images.githubusercontent.com/75403/64981326-1dfbc000-d8bc-11e9-9d16-48036f36b638.png"> Contributes to mono/mono#10641 Commit migrated from mono/mono@578e1a9

marek-safar added the task label Sep 17, 2018

marek-safar added this to Backlog in Short Term Projects via automation Sep 17, 2018

lewurm self-assigned this Nov 15, 2018

theodelrieu mentioned this issue Nov 20, 2018

watchOS architecture arm64_32 is not modeled in settings.yml conan-io/conan#3961

Closed

3 tasks

lewurm mentioned this issue Jan 23, 2019

[watch] add build rules for arm64_32 based on 2018-08-watchos branch xamarin/xamarin-macios#5465

Closed

marek-safar moved this from Backlog to In progress in Short Term Projects Mar 11, 2019

rolfbjarne mentioned this issue Aug 26, 2019

[watchos] Can't deploy with ARMv7k architecture on Series 4 xamarin/xamarin-macios#4864

Closed

This was referenced Sep 16, 2019

[arm64_32] fix remaining regression tests #16864

Closed

[arm64_32] make "Debug Mode" work on Watch series 4 with --interpreter #16865

Merged

monojenkins mentioned this issue Sep 17, 2019

[2019-08] [arm64_32] make "Debug Mode" work on Watch series 4 with --interpreter #16886

Merged

lewurm mentioned this issue Sep 17, 2019

ARM64_32 Debug Mode xamarin/xamarin-macios#7012

Merged

This was referenced Sep 20, 2019

[arm64_32] fix pointer size in CallInfo #16970

Merged

[threads] clear small_id_key TLS when unregistering a thread #16973

Merged

This was referenced Sep 21, 2019

[2019-08] [arm64_32] fix pointer size in CallInfo #16978

Merged

[2019-08] [threads] clear small_id_key TLS when unregistering a thread #17015

Merged

lewurm closed this as completed Sep 24, 2019

Short Term Projects automation moved this from In progress to Completed Tasks in this Sprint Sep 24, 2019

rolfbjarne reopened this Nov 11, 2019

Short Term Projects automation moved this from Completed Tasks in this Sprint to In progress Nov 11, 2019

rolfbjarne closed this as completed Nov 11, 2019

Short Term Projects automation moved this from In progress to Completed Tasks in this Sprint Nov 11, 2019

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

New arm64_32 architecture (watchOS 5) #10641

New arm64_32 architecture (watchOS 5) #10641

marek-safar commented Sep 17, 2018 •

edited by lewurm

Loading

lewurm commented Oct 2, 2018

lewurm commented Nov 15, 2018 •

edited

Loading

rolfbjarne commented Aug 26, 2019

lewurm commented Aug 26, 2019

lewurm commented Sep 24, 2019

onurhazar commented Nov 8, 2019

lewurm commented Nov 9, 2019

rolfbjarne commented Nov 11, 2019 •

edited

Loading

onurhazar commented Dec 20, 2019

New arm64_32 architecture (watchOS 5) #10641

New arm64_32 architecture (watchOS 5) #10641

Comments

marek-safar commented Sep 17, 2018 • edited by lewurm Loading

Milestone I (2018-10)

Milestone II (2019-08)

lewurm commented Oct 2, 2018

lewurm commented Nov 15, 2018 • edited Loading

rolfbjarne commented Aug 26, 2019

lewurm commented Aug 26, 2019

lewurm commented Sep 24, 2019

onurhazar commented Nov 8, 2019

lewurm commented Nov 9, 2019

rolfbjarne commented Nov 11, 2019 • edited Loading

onurhazar commented Dec 20, 2019

marek-safar commented Sep 17, 2018 •

edited by lewurm

Loading

lewurm commented Nov 15, 2018 •

edited

Loading

rolfbjarne commented Nov 11, 2019 •

edited

Loading