[Mono-list] Xamarin Bug #10857 - System.Data.SqlTypes.SqlDecimal on ARM

[Weeble]

On 11 April 2013 16:28, mickeyf <mickey at thesweetoasis.com> wrote:
> Bug referred to is  HERE.
> <https://bugzilla.xamarin.com/show_bug.cgi?id=10857>   This pretty well is a
> show stopper for doing anything with a DB on the ARM, since many of the
> higher level SQL classes refer to this whether it's actually going to be
> used or not. (My own DB could care less about 'Decimal')
>
> Since the ARM (BeagleBone in my case) is so much less mainstream than x86, I
> don't expect this to get immediate attention from the regular mono
> developers.
>
> So I'm wondering a couple of things:
>
> Is anyone on this list familiar with both this part of the mono code
> (SqlDataTypes), and working with ARM?

I have a little familiarity with ARM. I've cross-compiled mono for a
Sheevaplug (so soft-float only) and run and debugged code on the
device. I don't have much familiarity with SqlDataTypes, but I think I
can at least explain what's going on here.

> Has anyone else encountered this particular bug and consider is it important
> to you?
>
> Any clues as to what the issue might be? (I thought endianess, but x86 and
> ARM are both little endian..?)

You already posted a link to bug 7938 which explains what's wrong, if
only briefly. There's nothing wrong with SqlDecimal - the problem is
simply that hard-float is not supported. Any time you have code
compiled for soft-float (which I assume is what the ARM JIT outputs)
trying to call code compiled for hard-float, you will get undefined
behaviour. So long as floats or doubles aren't involved in the
function specification it will work, but as soon as they are, you will
find that at best the called function will get scrambled arguments,
and at worst the stack could be unbalanced, you'll get a segfault or
you'll see memory corruption. (Now that I think about it, the calling
convention is caller-cleanup, so you shouldn't actually see an
unbalanced stack in this case. Not that it's much consolation.)

SqlDecimal's constructor calls ToDouble, which calls Math.Pow, which
has a native implementation. It's probably at that point that
soft-float code is trying to call hard-float code and there's a
floating point argument involved. The soft-float code probably pushes
it onto the stack, while the hard-float code expects it to be in a
register. Disaster ensues.

I'm afraid that's about the extent of my knowledge. Good luck with the
hard-float patches. I'd be interested to know if they work.

> I have no way to use anything but a terminal window on my BeagleBone, so
> will may want to set up an ARM virtual machine for initial tests. Anyone
> done this and have suggestions?

I'm not sure that the virtual machine will be worth the hassle... What
will it let you do that you couldn't do on the device?

Regards,

Weeble.