Notice (2018-05-24): bugzilla.xamarin.com is now in
Please join us on
Visual Studio Developer Community and in the
Mono organizations on
GitHub to continue tracking issues. Bugzilla will remain
available for reference in read-only mode. We will continue to work
on open Bugzilla bugs, copy them to the new locations
as needed for follow-up, and add the new items under Related
Our sincere thanks to everyone who has contributed on this bug
tracker over the years. Thanks also for your understanding as we
make these adjustments and improvements for the future.
Please create a new report on
Developer Community or GitHub with
your current version information, steps to reproduce, and relevant error
messages or log files if you are hitting an issue that looks similar to
this resolved bug and you do not yet see a matching new report.
Created attachment 454 [details]
Create a new project from a template (for instance "MonoTouch Single View Application - Universal").
Change debugging target to iPhone|Debug.
Open project properties, in "iPhone Build" add --armv7 to additional mtouch arguments.
Put a breakpoint on the FinishedLaunching method in AppDelegate.cs (or anywhere else).
The app will now crash (see attached crash report).
Related forum posts:
AFAIK* to really enable 'arm7' you need to enable 'llvm' and that's not compatible with debugging.
My understanding was that the mono AOT compiler only supports 'arm6', which means only the ObjC glue code will be compiled under 'arm7' using --armv7 (not sure if that can cause issues or if the debugger handles this).
* mtouch currently does allow using --armv7 (and a few other options) without --llvm being specified.
Zoltan, do you have any input on this?
AFAIK Sebastien is correct, that's why the MD UI only permits targeting the ARMv7 arch if LLVM is enabled, and the LLVM option states that it's not compatible with debugging. The MD build code also validates this. By specifying the option using free-form "additional argument", you circumvent MD's validation, so I'd be inclined to call this user error.
However, I would propose that mtouch should error on --armv7 if LLVM isn't enabled, so other users don't encounter this problem.
The code generated by llvm can't be debugged right now, the UI should enforce this somehow.
We could easily disable the debugging commands in MD if the user has enabled LLVM in the project options, but it won't help in cases like this where they pass those options directly to mtouch.
I would suggest that
a) mtouch errors out if the user passes --armv7 or --fat without --llvm
b) when llvm is enabled, mtouch apps don't attempt to connect to the debugger
Not so sure about my comment #2 anymore wrt
Zoltan, does our (LLVM-less) AOT compiler supports ARMv7 ?
That's not something that was possible using mtouch (before the above commit) and also not possible using MonoDevelop addin UI.
> b) when llvm is enabled, mtouch apps don't attempt to connect to the debugger
That needs testing* but the --debug options is already ignored (and a warning is displayed) if --llvm is used (on mtouch command line).
* I assume that will stop it from connecting to the debugger.
MD now disables the debug command if the app has the LLVM option checked.
I'd still recommend that mtouch enforces the limitations, in case users circumvent MD's checks, such as in the original report.
mtouch already check and report (see below) when both --debug and --llvm are used. The debugger does not work in that case (e.g. no breakpoint will be hit) and the application works fine (but maybe it tries to connect since MD debugging dialog disappear).
warning: conflicting --debug and --llvm options. Soft-debugging is disabled.
However the original report is about using --arm7 *without* --llvm and that's still unclear to me if we support this or not. That's also unrelated to whether we support debugging with LLVM or not (comment #5) since using only --arm7 right now does not bring LLVM into the picture.
Once that's cleared up we have either:
a) not supported -> and no big deal to add checks for --arm7 (and --fat) to be used only when --llvm is available; or
b) supported -> and there's something else to fix wrt debugger
I have no idea what the --armv7 option actually does, I'd need the command line which is used to invoke the AOT compiler.
When the bug was filled (September 21th) the --armv7 did not do anything* on non-LLVM builds.
* wrt Mono but it did tell GCC it could use arm7 when compiling the (objective C) application stub
The revision noted in comment #7 (September 26th) changed that and shows the command-line arguments being build to call arm-darwin-mono. E.g. using --armv7 will produce something like:
MONO_PATH=/Users/sebastienpouliot/Downloads/TestMKMapViewDelegate/bin/iPhone/Debug/TestMKMapViewDelegate.app /Developer/MonoTouch/usr/bin/arm-darwin-mono --debug --aot=mtriple=armv7-darwin,full,static,asmonly,soft-debug,iphone-abi,outfile=/var/folders/fI/fIDK1klFH6yDR8NRb2cq-++++TI/-Tmp-/tmp6d17dc.tmp/TestMKMapViewDelegate.exe.7.s "/Users/sebastienpouliot/Downloads/TestMKMapViewDelegate/bin/iPhone/Debug/TestMKMapViewDelegate.app/TestMKMapViewDelegate.exe"
Still unclear if we support, without LLVM, using AOT with ARM7 instructions ?
It should work, but it looks like it doesn't. I think we should disable armv7+debugging too until this is fixed, and keep the bug open.
Ok, so ARMv7 supported by our AOT compiler - but without debugging (until this bug is fixed). I'll make this change to mtouch.
Does it means we can also support FAT binaries with the AOT compiler (i.e. without LLVM) ?
And what about thumb2 support ?
The JIT only supports a few ARMv7 instructions and doesn't support thumb2 at all.
armv7 + debug check added in 5ae2459b539b6ac7c36c27b2448ca6c9edff4c20 (master)
to be removed once this bug is fixed
So this is what I've found out:
* It only crashes when attaching the debugger.
* Disabling the special armv7 handling in mini-arm.c doesn't change anything.
* Anything can happen (it may throw managed exceptions, of different kinds and in different locations, it may crash, it may deadlock, etc).
* It is not necessary to have any breakpoints for it to crash.
The underlying runtime issue should be fixed now.
the check from comment #15 is removed