[Mono-dev] marshalbool.cs is failing for PPC, dont understand why this would work on x86_64.
Steven Munroe
munroesj at us.ibm.com
Sat May 30 11:37:36 EDT 2009
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
>
>
More information about the Mono-devel-list
mailing list