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.

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

Assertion on 32-bit iOS device with thumb code #14247

Closed
rolfbjarne opened this issue Apr 26, 2019 · 3 comments · Fixed by #14288 or xamarin/xamarin-android#3105

Comments

@rolfbjarne
Copy link
Member

@rolfbjarne rolfbjarne commented Apr 26, 2019

Steps to Reproduce

  1. Build xamarin-macios/master as of today (for instance xamarin/xamarin-macios@6c36746)
  2. cd tests && make runner to launch the test runner in the browser
  3. Run the monotouch-test/iOS Unified 32-bits - device/Release: UseThumb test.

This requires an iOS device that supports 32-bit (i.e. with iOS 10.3 or earlier).

I currently don't know when this regressed, since we very recently started to run monotouch-test in thumb mode.

Current Behavior

Assert at launch.

This shows in the device log:

monotouchtest[1024] : * Assertion at ../../../../../mono/mini/tramp-arm.c:1130, condition `(t1 >> 11) == 0x1e' not met

Application Output
Crash report

Expected Behavior

No crash

@marek-safar

This comment has been minimized.

Copy link
Member

@marek-safar marek-safar commented Apr 30, 2019

@vargaz could you please look into this regression

@vargaz

This comment has been minimized.

Copy link
Member

@vargaz vargaz commented Apr 30, 2019

What seems to happen is that llvm's llc doesn't generate thumb code even if we ask it to:
/Users/vargaz/mt/master/xamarin-macios/_ios-build/Library/Frameworks/Xamarin.iOS.framework/Versions/git/LLVM36/bin/llc" -march=arm -mattr=+v7 -mattr=+vfp2,-neon,+d16 -asm-verbose=false -mtriple=thumbv7-ios -disable-gnu-eh-frame -enable-mono-eh-frame -mono-eh-frame-symbol=_mono_aot_mscorlib_eh_frame -relocation-model=pic -filetype=obj -o "/Users/vargaz/mt/master/xamarin-macios/tests/xharness/tmp-test-dir/monotouch-test1099/obj/iPhone/Release32-unified/mtouch-cache/armv7/mscorlib.dll-llvm.o" "/Users/vargaz/mt/master/xamarin-macios/tests/xharness/tmp-test-dir/monotouch-test1099/obj/iPhone/Release32-unified/mtouch-cache/armv7/mscorlib.dll.s.opt.bc

The -mtriple=thumb7-ios flag is supposed to force the generation of thumb code.

(__TEXT,__text) section
_mscorlib_Interop_ThrowExceptionForIoErrno_Interop_ErrorInfo_string_bool_System_Func_2_Interop_ErrorInfo_Interop_ErrorInfo:
00000000 f0 40 2d e9 push {r4, r5, r6, r7, lr}
00000004 0c 70 8d e2 add r7, sp, #12
00000008 04 a0 2d e5 str r10, [sp, #-0x4]!

@vargaz

This comment has been minimized.

Copy link
Member

@vargaz vargaz commented Apr 30, 2019

Apparently passing -march=arm and -mtriple=thumbv7-ios at the same time is not a good idea.

vargaz added a commit to vargaz/mono that referenced this issue Apr 30, 2019
monojenkins added a commit to monojenkins/mono that referenced this issue Apr 30, 2019
@vargaz vargaz closed this in #14288 May 1, 2019
vargaz added a commit that referenced this issue May 1, 2019
…32 code generation. (#14288)

Fixes #14247.
monojenkins added a commit to monojenkins/mono that referenced this issue May 1, 2019
marek-safar added a commit that referenced this issue May 1, 2019
…32 code generation.

Fixes #14247.
marek-safar added a commit that referenced this issue May 2, 2019
…32 code generation.

Fixes #14247.
grendello added a commit to grendello/xamarin-android that referenced this issue May 22, 2019
Add build-time support for *Windows* [mono archives][0].

Context: [xamarin-android/d16-2-with-mono-2018-10-via-6e8a50ea][1]
Context: mono/mono#14307
Context: mono/mono#14333

Fixes: mono/mono#13150
Fixes: mono/mono#14223
Fixes: mono/mono#14247
Fixes: mono/mono#14290

The [Xamarin.Android Designer][2] is an interesting beast: it runs a
Xamarin.Android-like Java stack on desktop macOS and Windows.  A Java
process is created, and that Java process loads:

  * *Desktop* Mono via `libmonosgen-2.0.dylib` (macOS)` or
    `libmonosgen-2.0.dll` (Windows).`
  * The Xamarin.Android runtime via `libmono-android.debug.dylib`
    (macOS) or `libmono-android.debug.dll` (Windows)
  * Other Java code (to render items to the screen)
  * `Mono.Android.dll` and other user assemblies (to render items to
    the screen).

Being "interesting" means it introduces all kinds of "fun":
`libmono-android.debug.dll` needs to be built *for Windows* (which is
why there's `#if WINDOWS` within `src/monodroid`),
`libmonosgen-2.0.dll` needs to be built for Windows (not a huge
issue), and -- "equally" important but *more* important regarding the
next few paragraphs! -- `mscorlib.dll` needs to target Windows.

`mscorlib.dll` is where things get annoying.  Once Upon A Time™,
Mono's `mscorlib.dll` was platform agnostic: build it for one
platform, it would run everywhere, as it would internally perform
runtime OS-checks to behave appropriately on Unix/Windows/etc.

That hasn't been true for awhile, but the Xamarin.Android build and
install environment still assumes it to be true.  Consequently, a
"Unix" `mscorlib.dll` is used by the Designer on Windows.  This
[*apparently* (?)][3] hasn't blown up catastrophically before, but
with the mono/2019-02 migration (b8c30f9) we have now entered
"catastrophic" territory: [Designer integration tests on Windows][4]
may fail because `System.Native` cannot be found:

	System.TypeInitializationException: The type initializer for 'System.Console' threw an exception. ---> System.DllNotFoundException: System.Native

The fix?  We need a *Windows*-targeting build of `mscorlib.dll` and
other BCL assemblies, in this case one that *doesn't* use the
`System.Native` native library in P/Invokes.

Enter the [Multi-platform monodroid BCL builds mono epic][5]: instead
of mono building and providing a *single* "mono archive" which
contains files for *every* supported architecture (macOS, Windows,
Android), mono will instead provide [*multiple* mono archives][6],
each supporting a particular subset.  For example, the
[archives for mono/2019-02@0bd00ec][7] include:

  * `android-release-Windows-0bd00ec58809f2a6ec5feff587b1117255b080fd.zip`:
    `monodroid`-profile BCL assemblies built to run on Windows.

  * `android-release-Darwin-0bd00ec58809f2a6ec5feff587b1117255b080fd.zip`:
    `monodroid`-profile BCl assemblies built to run on macOS, *and*
    `libmonosgen-2.0.dylib` for macOS, *and* `libmonosgen-2.0.dll`
    for Win32 & Win64, *and*...everything else (for now).

Thus, the fix for Designer-on-Windows: Download *all* required mono
archives (both Darwin & Windows for now) -- not just the Darwin
archive -- and extract those archives where the xamarin-android build
requires them to be.

Host-specific BCL files are placed into the
`$(MonoAndroidBinDirectory)\bcl`, e.g. the macOS-targeting
`mscorlib.dll` will be installed into:

	…/lib/xamarin.android/xbuild/Xamarin/Android/Darwin/bcl/mscorlib.dll

While Windows (currently) omits the OS name, and will install into:

	…/Xamarin/Android/bcl/mscorlib.dll

TODO:

  * Many of the host-specific BCL assemblies are "identical enough"
    to the Android-targeting BCL assemblies, e.g. the only difference
    between `System.Net.dll` for Windows & Android is the MVID GUID.
    We could be smarter about which files we redistribute, which
    would shrink the installation size.

  * Stop special-casing Windows within `$(MonoAndroidBinDirectory)`.
    Windows-specific files such as `cross-arm.exe` should be
    installed into `…/Xamarin/Android/Windows/cross-arm.exe`, and
    use `…/Xamarin/Android/Windows/bcl/mscorlib.dll` for the
    Windows-targeting monodroid-profile `mscorlib.dll`.

[0]: https://github.com/xamarin/xamarin-android/projects/10
[1]: xamarin@1f003cc
[2]: https://docs.microsoft.com/en-us/xamarin/android/user-interface/android-designer/
[3]: https://developercommunity.visualstudio.com/content/problem/440975/xamarin-xaml-designer-still-fails.html
[4]: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=2634805
[5]: mono/mono#14333
[6]: https://jenkins.mono-project.com/view/All/job/archive-mono/
[7]: https://jenkins.mono-project.com/view/All/job/archive-mono/job/2019-02/232/Azure/
jonpryor added a commit to xamarin/xamarin-android that referenced this issue May 22, 2019
Add build-time support for *Windows* [mono archives][0].

Context: [xamarin-android/d16-2-with-mono-2018-10-via-6e8a50ea][1]
Context: mono/mono#14307
Context: mono/mono#14333

Fixes: mono/mono#13150
Fixes: mono/mono#14223
Fixes: mono/mono#14247
Fixes: mono/mono#14290

The [Xamarin.Android Designer][2] is an interesting beast: it runs a
Xamarin.Android-like Java stack on desktop macOS and Windows.  A Java
process is created, and that Java process loads:

  * *Desktop* Mono via `libmonosgen-2.0.dylib` (macOS)` or
    `libmonosgen-2.0.dll` (Windows).`
  * The Xamarin.Android runtime via `libmono-android.debug.dylib`
    (macOS) or `libmono-android.debug.dll` (Windows)
  * Other Java code (to render items to the screen)
  * `Mono.Android.dll` and other user assemblies (to render items to
    the screen).

Being "interesting" means it introduces all kinds of "fun":
`libmono-android.debug.dll` needs to be built *for Windows* (which is
why there's `#if WINDOWS` within `src/monodroid`),
`libmonosgen-2.0.dll` needs to be built for Windows (not a huge
issue), and -- "equally" important but *more* important regarding the
next few paragraphs! -- `mscorlib.dll` needs to target Windows.

`mscorlib.dll` is where things get annoying.  Once Upon A Time™,
Mono's `mscorlib.dll` was platform agnostic: build it for one
platform, it would run everywhere, as it would internally perform
runtime OS-checks to behave appropriately on Unix/Windows/etc.

That hasn't been true for awhile, but the Xamarin.Android build and
install environment still assumes it to be true.  Consequently, a
"Unix" `mscorlib.dll` is used by the Designer on Windows.  This
[*apparently* (?)][3] hasn't blown up catastrophically before, but
with the mono/2019-02 migration (b8c30f9) we have now entered
"catastrophic" territory: [Designer integration tests on Windows][4]
may fail because `System.Native` cannot be found:

	System.TypeInitializationException: The type initializer for 'System.Console' threw an exception. ---> System.DllNotFoundException: System.Native

The fix?  We need a *Windows*-targeting build of `mscorlib.dll` and
other BCL assemblies, in this case one that *doesn't* use the
`System.Native` native library in P/Invokes.

Enter the [Multi-platform monodroid BCL builds mono epic][5]: instead
of mono building and providing a *single* "mono archive" which
contains files for *every* supported architecture (macOS, Windows,
Android), mono will instead provide [*multiple* mono archives][6],
each supporting a particular subset.  For example, the
[archives for mono/2019-02@0bd00ec][7] include:

  * `android-release-Windows-0bd00ec58809f2a6ec5feff587b1117255b080fd.zip`:
    `monodroid`-profile BCL assemblies built to run on Windows.

  * `android-release-Darwin-0bd00ec58809f2a6ec5feff587b1117255b080fd.zip`:
    `monodroid`-profile BCl assemblies built to run on macOS, *and*
    `libmonosgen-2.0.dylib` for macOS, *and* `libmonosgen-2.0.dll`
    for Win32 & Win64, *and*...everything else (for now).

Thus, the fix for Designer-on-Windows: Download *all* required mono
archives (both Darwin & Windows for now) -- not just the Darwin
archive -- and extract those archives where the xamarin-android build
requires them to be.

Host-specific BCL files are placed into the
`$(MonoAndroidBinDirectory)\bcl`, e.g. the macOS-targeting
`mscorlib.dll` will be installed into:

	…/lib/xamarin.android/xbuild/Xamarin/Android/Darwin/bcl/mscorlib.dll

While Windows (currently) omits the OS name, and will install into:

	…/Xamarin/Android/bcl/mscorlib.dll

TODO:

  * Many of the host-specific BCL assemblies are "identical enough"
    to the Android-targeting BCL assemblies, e.g. the only difference
    between `System.Net.dll` for Windows & Android is the MVID GUID.
    We could be smarter about which files we redistribute, which
    would shrink the installation size.

  * Stop special-casing Windows within `$(MonoAndroidBinDirectory)`.
    Windows-specific files such as `cross-arm.exe` should be
    installed into `…/Xamarin/Android/Windows/cross-arm.exe`, and
    use `…/Xamarin/Android/Windows/bcl/mscorlib.dll` for the
    Windows-targeting monodroid-profile `mscorlib.dll`.

[0]: https://github.com/xamarin/xamarin-android/projects/10
[1]: 1f003cc
[2]: https://docs.microsoft.com/en-us/xamarin/android/user-interface/android-designer/
[3]: https://developercommunity.visualstudio.com/content/problem/440975/xamarin-xaml-designer-still-fails.html
[4]: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=2634805
[5]: mono/mono#14333
[6]: https://jenkins.mono-project.com/view/All/job/archive-mono/
[7]: https://jenkins.mono-project.com/view/All/job/archive-mono/job/2019-02/232/Azure/
jonpryor added a commit to xamarin/xamarin-android that referenced this issue May 22, 2019
Add build-time support for *Windows* [mono archives][0].

Context: [xamarin-android/d16-2-with-mono-2018-10-via-6e8a50ea][1]
Context: mono/mono#14307
Context: mono/mono#14333

Fixes: mono/mono#13150
Fixes: mono/mono#14223
Fixes: mono/mono#14247
Fixes: mono/mono#14290

The [Xamarin.Android Designer][2] is an interesting beast: it runs a
Xamarin.Android-like Java stack on desktop macOS and Windows.  A Java
process is created, and that Java process loads:

  * *Desktop* Mono via `libmonosgen-2.0.dylib` (macOS)` or
    `libmonosgen-2.0.dll` (Windows).`
  * The Xamarin.Android runtime via `libmono-android.debug.dylib`
    (macOS) or `libmono-android.debug.dll` (Windows)
  * Other Java code (to render items to the screen)
  * `Mono.Android.dll` and other user assemblies (to render items to
    the screen).

Being "interesting" means it introduces all kinds of "fun":
`libmono-android.debug.dll` needs to be built *for Windows* (which is
why there's `#if WINDOWS` within `src/monodroid`),
`libmonosgen-2.0.dll` needs to be built for Windows (not a huge
issue), and -- "equally" important but *more* important regarding the
next few paragraphs! -- `mscorlib.dll` needs to target Windows.

`mscorlib.dll` is where things get annoying.  Once Upon A Time™,
Mono's `mscorlib.dll` was platform agnostic: build it for one
platform, it would run everywhere, as it would internally perform
runtime OS-checks to behave appropriately on Unix/Windows/etc.

That hasn't been true for awhile, but the Xamarin.Android build and
install environment still assumes it to be true.  Consequently, a
"Unix" `mscorlib.dll` is used by the Designer on Windows.  This
[*apparently* (?)][3] hasn't blown up catastrophically before, but
with the mono/2019-02 migration (b8c30f9) we have now entered
"catastrophic" territory: [Designer integration tests on Windows][4]
may fail because `System.Native` cannot be found:

	System.TypeInitializationException: The type initializer for 'System.Console' threw an exception. ---> System.DllNotFoundException: System.Native

The fix?  We need a *Windows*-targeting build of `mscorlib.dll` and
other BCL assemblies, in this case one that *doesn't* use the
`System.Native` native library in P/Invokes.

Enter the [Multi-platform monodroid BCL builds mono epic][5]: instead
of mono building and providing a *single* "mono archive" which
contains files for *every* supported architecture (macOS, Windows,
Android), mono will instead provide [*multiple* mono archives][6],
each supporting a particular subset.  For example, the
[archives for mono/2019-02@0bd00ec][7] include:

  * `android-release-Windows-0bd00ec58809f2a6ec5feff587b1117255b080fd.zip`:
    `monodroid`-profile BCL assemblies built to run on Windows.

  * `android-release-Darwin-0bd00ec58809f2a6ec5feff587b1117255b080fd.zip`:
    `monodroid`-profile BCl assemblies built to run on macOS, *and*
    `libmonosgen-2.0.dylib` for macOS, *and* `libmonosgen-2.0.dll`
    for Win32 & Win64, *and*...everything else (for now).

Thus, the fix for Designer-on-Windows: Download *all* required mono
archives (both Darwin & Windows for now) -- not just the Darwin
archive -- and extract those archives where the xamarin-android build
requires them to be.

Host-specific BCL files are placed into the
`$(MonoAndroidBinDirectory)\bcl`, e.g. the macOS-targeting
`mscorlib.dll` will be installed into:

	…/lib/xamarin.android/xbuild/Xamarin/Android/Darwin/bcl/mscorlib.dll

While Windows (currently) omits the OS name, and will install into:

	…/Xamarin/Android/bcl/mscorlib.dll

TODO:

  * Many of the host-specific BCL assemblies are "identical enough"
    to the Android-targeting BCL assemblies, e.g. the only difference
    between `System.Net.dll` for Windows & Android is the MVID GUID.
    We could be smarter about which files we redistribute, which
    would shrink the installation size.

  * Stop special-casing Windows within `$(MonoAndroidBinDirectory)`.
    Windows-specific files such as `cross-arm.exe` should be
    installed into `…/Xamarin/Android/Windows/cross-arm.exe`, and
    use `…/Xamarin/Android/Windows/bcl/mscorlib.dll` for the
    Windows-targeting monodroid-profile `mscorlib.dll`.

[0]: https://github.com/xamarin/xamarin-android/projects/10
[1]: 1f003cc
[2]: https://docs.microsoft.com/en-us/xamarin/android/user-interface/android-designer/
[3]: https://developercommunity.visualstudio.com/content/problem/440975/xamarin-xaml-designer-still-fails.html
[4]: https://devdiv.visualstudio.com/DevDiv/_build/results?buildId=2634805
[5]: mono/mono#14333
[6]: https://jenkins.mono-project.com/view/All/job/archive-mono/
[7]: https://jenkins.mono-project.com/view/All/job/archive-mono/job/2019-02/232/Azure/
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
4 participants
You can’t perform that action at this time.