On Fri, 2012-02-03 at 00:25 +0100, Alexander Graf wrote:

On 03.02.2012, at 00:22, Jo Shields wrote:

...

On Fri, 2012-02-03 at 00:15 +0100, Alexander Graf wrote:

...

On 03.02.2012, at 00:11, Hector Oron wrote:

...

Hello Jo,

I am forwarding the message to a couple mailing lists which might have people interested on the Mono porting for ARM hard-float ABI.

2012/2/2 Jo Shields :

...

Right now, Mono is available in Debian armhf. This is a hack - what we're actually doing is building Mono as an armhf binary, but built to emit soft VFP instructions and using calling conventions and ABI for armel. This hack works well enough for pure cross-platform code (like the C# compiler) to run, but dies in a heap for anything complex.

This situation is a bit on the crappy side of crap.

In order for Mono on armhf not to be a waste of time, a "true" port needs to be completed. If I were to make a not-remotely-educated guess, I'd say it needs about 550 lines of changes, primarily the addition of code to emit the correct instructions feeling the correct registers in mono/mini/mini-arm.c plus a couple of tweaks to related headers.

Upstream have also indicated that they're happy to provide guidance and pointers on how to implement this port, although they're unable to provide the requisite code themselves.

Sadly, unless someone in the community is able to step forward and contribute here, it's only a matter of time before the armhf packages are rightfully marked RC-buggy, and 100+ packages need to be axed from armhf. This would make me sad.

Please check our mono arm patches in OBS:

https://build.opensuse.org/package/files?package=mono-core&project=openSUSE%3AFactory%3AARM

While slightly hacky, they enable full armhf support for arm. At least for us it's worked pretty well. Mono is a rather core dependency of a lot of stuff.

Are these really giving you everything you need for openSUSE w/ hardfloat? They don't really seem very different from what we're doing in Debian, i.e. using the existing VFP softfloat code

Yes. At least the native library bindings seem to work :). But I haven't stress tested it. Do you have an example of where it breaks for you?

I think Hector had some examples of real-world apps that weren't working when he tested - it's a while since I tried to get X working on ArmHF on my EfikaMX so I didn't get much chance to try myself. In the general case, we run the runtime portion of the Mono test suite during the build process, so we have logs to refer to for this stuff. Basic stuff like math accuracy is done via "cd mono/mini && make check", and more general tests of runtime capabilities via "cd mono/tests && make test" - once with MONO_ENV_OPTIONS=--gc=boehm for the old Boehm GC, and once with MONO_ENV_OPTIONS=--gc=sgen for the fancy new one. The latest build logs for our regular ARM build (v5, no FPU) are at https://buildd.debian.org/status/fetch.php?pkg=mono&arch=armel&ver=2.10.5-2&stamp=1326714448 and for ArmHF (v7, hard VFP) are at https://buildd.debian.org/status/fetch.php?pkg=mono&arch=armhf&ver=2.10.5-2&stamp=1326712108 The number of passes in the basic arithmetic falls from 100% to 96.76%, and the number of failing runtime tests jumps from 2 fairly minor ones to 9, including the fairly crucial basic P/Invoke marshalling tests. It's the failures in the pinvoke, pinvoke2 and pinvoke3 tests that worry me, since it means any C library bindings like GTK# are on pretty wobbly ground