[Mono-dev] marshalbool.cs is failing for PPC, dont understand why this would work on x86_64.

Zoltan Varga vargaz at gmail.com
Sat May 30 10:34:47 EDT 2009


Hi,

The last argument is marshalled as VariantBool:

                            [MarshalAs (UnmanagedType.VariantBool)]
bool bVBCustMarsh);

VariantBool is marshalled as: (2 bytes, VARIANT_TRUE = 0xFFFF, VARIANT_FALSE
= 0)

so the the C function should receive 0xffff in bVBCustMarsh, not 1. No idea
why this happens
on ppc.

                                    Zoltan

On Sat, May 30, 2009 at 3:36 AM, Steven Munroe <munroesj at us.ibm.com> wrote:

> The test:
>
>    unsafe public static int test_0_VariantBool_In_Native ()
>    {
>        int ret;
>
>        ret = mono_test_marshal_bool_in (5, 0, false, false, false,
> false, false);
>        if (ret != 0)
>            return 0x0100 + ret;
>        ret = mono_test_marshal_bool_in (5, 0xFFFF, false, false, false,
> false, true);
>        if (ret != 0)
>            return 0x0200 + ret;
>
>        bool testVal = false;
>        bool* ptestVal = &testVal;
>
>        Marshal.WriteByte ((IntPtr)ptestVal, 0x22);
>        ret = mono_test_marshal_bool_in (5, 0xFFFF, false, false, false,
> false, testVal);
>        if (ret != 0)
>            return 0x0300 + ret;
>
>        return 0;
>    }
>
> is failing specifically:
>
>        ret = mono_test_marshal_bool_in (5, 0xFFFF, false, false, false,
> false, true);
>        if (ret != 0)
>            return 0x0200 + ret;
>
> In PPC we pass 0x00000005 parm arg in R3, 0x0000FFFF to parm "expected"
> in R4 and 0x00000001 parm bVBCustMarsh in R9 to
> mono_test_marshal_bool_in. The Implementation of
> mono_test_marshal_bool_in is:
>
> LIBTEST_API int STDCALL
> mono_test_marshal_bool_in (int arg, unsigned int expected, unsigned int
> bDefaultMarsh, unsigned int bBoolCustMarsh,
>               char bI1CustMarsh, unsigned char bU1CustMarsh, unsigned
> short bVBCustMarsh)
> {
>    switch (arg) {
>    case 1:
>        if (bDefaultMarsh != expected)
>            return 1;
>        break;
>    case 2:
>        if (bBoolCustMarsh != expected)
>            return 2;
>        break;
>    case 3:
>        if (bI1CustMarsh != expected)
>            return 3;
>        break;
>    case 4:
>        if (bU1CustMarsh != expected)
>            return 4;
>        break;
>    case 5:
>        if (bVBCustMarsh != expected)
>            return 5;
>        break;
>    default:
>        return 999;
>    }
>    return 0;
> }
>
> In this case
>
>        if (bVBCustMarsh != expected)
>            return 5;
>
> will compare 0x0000FFFF != 0x00000001 and return 5.
>
> There seems to be a number of problems with this test and its not clean
> why it (appears to) work for x86_64. In marshalbool.cs we see
> mono_test_marshal_bool_in declared as:
>
>    [DllImport ("libtest")]
>    static extern int mono_test_marshal_bool_in (int arg, uint expected,
>                             bool bDefaultMarsh,
>                             [MarshalAs (UnmanagedType.Bool)] bool
> bBoolCustMarsh,
>                             [MarshalAs (UnmanagedType.I1)] bool
> bI1CustMarsh,
>                             [MarshalAs (UnmanagedType.U1)] bool
> bU1CustMarsh,
>                             [MarshalAs (UnmanagedType.VariantBool)]
> bool bVBCustMarsh);
>
> Which does not match the declaration on libtest.c:
>
> LIBTEST_API int STDCALL
> mono_test_marshal_bool_in (int arg, unsigned int expected, unsigned int
> bDefaultMarsh, unsigned int bBoolCustMarsh,
>               char bI1CustMarsh, unsigned char bU1CustMarsh, unsigned
> short bVBCustMarsh)
>
> I don't see how this test is supposed to work (0x0000FFFF != 0x00000001)
> especially as we are comparing a unsigned int to a unsigned short?
>
>
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.ximian.com/pipermail/mono-devel-list/attachments/20090530/cccf341d/attachment-0001.html 


More information about the Mono-devel-list mailing list