Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

New arm64_32 architecture (watchOS 5) #10641

Closed
2 of 3 tasks
marek-safar opened this issue Sep 17, 2018 · 9 comments
Closed
2 of 3 tasks

New arm64_32 architecture (watchOS 5) #10641

marek-safar opened this issue Sep 17, 2018 · 9 comments
Assignees
@lewurm
Labels
task

Comments

@marek-safar
Copy link
Member

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

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.
@lewurm
Copy link
Contributor

lewurm commented Oct 2, 2018

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 lewurm self-assigned this Nov 15, 2018
@lewurm
Copy link
Contributor

lewurm commented Nov 15, 2018 •
edited
Loading

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

Release mode:

Debug mode:

@theodelrieu theodelrieu mentioned this issue Nov 20, 2018
Closed
3 tasks
This was referenced Jan 15, 2019
Merged
Closed
Merged
Merged
Closed
@lewurm lewurm mentioned this issue Jan 23, 2019
Closed
@rolfbjarne
Copy link
Member

@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?

@rolfbjarne rolfbjarne mentioned this issue Aug 26, 2019
Closed
@lewurm
Copy link
Contributor

lewurm commented Aug 26, 2019

@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.

This was referenced Sep 16, 2019
Closed
Merged
monojenkins pushed a commit that referenced this issue Sep 17, 2019
@lewurm @monojenkins
[arm64_32] make "Debug Mode" work on Watch series 4 with --interpreter (
578e1a9 
#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
@monojenkins monojenkins mentioned this issue Sep 17, 2019
Merged
@lewurm lewurm mentioned this issue Sep 17, 2019
Merged
monojenkins added a commit that referenced this issue Sep 17, 2019
@monojenkins
[2019-08] [arm64_32] make "Debug Mode" work on Watch series 4 with --…
a0e7f9e 
…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
This was referenced Sep 20, 2019
Merged
Merged
This was referenced Sep 21, 2019
Merged
Merged
@lewurm
Copy link
Contributor

lewurm commented Sep 24, 2019

Related changes have been landed into 2019-08.

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

@lewurm lewurm closed this as completed Sep 24, 2019
monojenkins added a commit that referenced this issue Sep 24, 2019
@monojenkins
[2019-08] [threads] clear small_id_key TLS when unregistering a thread (
af008b2 
#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
Copy link

@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
Copy link
Contributor

lewurm commented Nov 9, 2019

@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
Copy link
Member

rolfbjarne commented Nov 11, 2019 •
edited
Loading

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

@rolfbjarne rolfbjarne reopened this Nov 11, 2019
@onurhazar
Copy link

@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.

ManickaP pushed a commit to ManickaP/runtime that referenced this issue Jan 20, 2020
@lewurm @monojenkins
[arm64_32] make "Debug Mode" work on Watch series 4 with --interpreter (
d4c0136 
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees

@lewurm lewurm

Labels
task
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@lewurm @rolfbjarne @marek-safar @onurhazar