[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 11:52:56 EDT 2009
Hi,
There is a method called a managed-to-native wrapper between the test
method and the
C function, this method is generated by the runtime, in marshal.c, and it
does the marshalling of parameters, in this case, it should convert the
'true' value to a 0xffff.
Also, I can't reproduce this failure on either ppc or ppc64 (debian).
Zoltan
On Sat, May 30, 2009 at 5:37 PM, Steven Munroe <munroesj at us.ibm.com> wrote:
> Zoltan Varga wrote:
> > 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
>
> This is strange as it appears that x86_64 is also passing 1 to the 7th
> parm bVBCustMarsh.
>
> 0000000000000000 <shalbool_test_0_VariantBool_In_Native>:
> <BB>:3
> 0: 55 push %rbp
> 1: 48 8b ec mov %rsp,%rbp
> 4: 41 56 push %r14
> 6: 48 83 ec 28 sub $0x28,%rsp
> a: c6 45 ef 00 movb $0x0,-0x11(%rbp)
> /* 1st call to mono_test_marshal_bool_in (5, 0, false, false, false,
> false, false);
> Note the 7th parm is passed on the stack and set to 0 */
> e: 48 c7 04 24 00 00 00 movq $0x0,(%rsp)
> 15: 00
> 16: bf 05 00 00 00 mov $0x5,%edi
> 1b: 33 f6 xor %esi,%esi
> 1d: 33 d2 xor %edx,%edx
> 1f: 33 c9 xor %ecx,%ecx
> 21: 45 33 c0 xor %r8d,%r8d
> 24: 45 33 c9 xor %r9d,%r9d
> 27: e8 53 fb ff ff callq fffffffffffffb7f
> <shalbool_test_0_VariantBool_In_Native+0xfffffffffffffb7f>
> 2c: 4c 8b f0 mov %rax,%r14
> 2f: 45 85 f6 test %r14d,%r14d
> 32: 74 0d je 41
> <shalbool_test_0_VariantBool_In_Native+0x41>
> <BB>:5
> 34: 49 8b c6 mov %r14,%rax
> 37: 05 00 01 00 00 add $0x100,%eax
> 3c: e9 94 00 00 00 jmpq d5
> <shalbool_test_0_VariantBool_In_Native+0xd5>
> <BB>:4
> /* 2nd call to mono_test_marshal_bool_in (5, 0xFFFF, false, false,
> false, false, true);
> Note the 7th parm is set to 0x1 not 0xffff */
> 41: 48 c7 04 24 01 00 00 movq $0x1,(%rsp)
> 48: 00
> 49: bf 05 00 00 00 mov $0x5,%edi
> 4e: be ff ff 00 00 mov $0xffff,%esi
> 53: 33 d2 xor %edx,%edx
> 55: 33 c9 xor %ecx,%ecx
> 57: 45 33 c0 xor %r8d,%r8d
> 5a: 45 33 c9 xor %r9d,%r9d
> 5d: 66 90 xchg %ax,%ax
> 5f: e8 1b fb ff ff callq fffffffffffffb7f
> <shalbool_test_0_VariantBool_In_Native+0xfffffffffffffb7f>
>
> So if [MarshalAs (UnmanagedType.VariantBool)] should result in
> generating a 0xffff for true then x86_64 is broken to.
> >
> >
> > On Sat, May 30, 2009 at 3:36 AM, Steven Munroe <munroesj at us.ibm.com
> > <mailto: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
> > <mailto: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/e7b3f30d/attachment-0001.html
More information about the Mono-devel-list
mailing list