When detecting the platform version for ARM CPU's you check /proc/cpuinfo for a line that starts with "Processor" and then extract the version (see https://github.com/mono/mono/blob/51137702c64076f6f7af9a08c1bafc766f5cf6d2/mono/utils/mono-hwcap-arm.c#L114). On my Raspberry PI that runs OSMC /proc/cpuinfo looks like this:
processor : 0
model name : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS : 847.52
Features : half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant : 0x0
CPU part : 0xb76
CPU revision : 7
Hardware : BCM2708
Revision : 0010
Serial : 0000000094e1d959
So it seems that the important line here doesn't start with "Processor" but with "model name".
So Mono obviously thinks that it runs on a different CPU and everytime I run a .NET application I just get "Illegal instruction" and the program exits.
There is a similar issue in nodejs (see https://github.com/nodejs/node/issues/283).
I've installed mono according to http://www.mono-project.com/docs/getting-started/install/linux/, `apt-cache policy mono-complete` gives me:
*** 22.214.171.124-0xamarin1 0
500 http://download.mono-project.com/repo/debian/ wheezy/main armhf Packages
500 http://mirrordirector.raspbian.org/raspbian/ jessie/main armhf Packages
Do you have the auxv.h header on your system? If so, a relatively simple workaround is to build Mono yourself.
The problem is that we're building our armhf packages on Debian wheezy which doesn't have the header. So Mono gets built to use the /proc/cpuinfo method which is, as you've seen, not very well tested and kinda buggy.
We'll need to have a look at whether we can improve the packaging situation, but there's definitely a bug to be fixed in the code that parses /proc/cpuinfo.
Thanks for your response.
I installed libc6-dev and now I have auxv.h.
So you mean if auxv.h is available /proc/cpuinfo is not needed and it should work when I build it myself without making any changes to the source code?
That's correct. If Mono finds that header at build time, it'll use the getauxval () function from glibc instead of parsing any /proc files.
Ok thanks for your help. Feel free to close this issue.
Hang on... which model of Pi is this?
SIGILL is correct for our Hard Float packages on Pi 1, which are compiled against a standard Debian armhf profile (i.e. ARMv7) and will not run on an ARMv6 chip