Ah... I hadn't tried it on a platform with soft-FP. And true enough, the compiler wouldn't support the VFP coprocessor instructions without hardware floats. It could be made to work with soft-FP too, but would at least be a different function for the assembly language part to one that excludes the VFP coprocessor instructions.
I think the correct answer for now would be to do the !defined(__SOFTFP__) in my code, just as described in the discussion at the link you sent. It seems correct since this code is explicitly written for hard-FP.
Please let me know if that's acceptable, and I will add that check and submit a v4 of the patch.
Also, another thing you will hit, that I mentioned in a previous discussion, is the test suite for this module. Currently, there is the following in tests/typelib.c:
static const BOOL is_win64 = sizeof(void *) > sizeof(int); ... /* the function checks the argument sizes for stdcall */ if (!is_win64) /* no stdcall on 64-bit */ { res = DispCallFunc( NULL, (ULONG_PTR)stdcall_func, CC_STDCALL, VT_UI4, 0, types, pargs, &result ); ok( res == DISP_E_BADCALLEE, "DispCallFunc wrong error %x\n", res ); res = DispCallFunc( NULL, (ULONG_PTR)stdcall_func, CC_STDCALL, VT_UI4, 1, types, pargs, &result ); ok( res == S_OK, "DispCallFunc failed %x\n", res ); res = DispCallFunc( NULL, (ULONG_PTR)stdcall_func, CC_STDCALL, VT_UI4, 2, types, pargs, &result ); ok( res == DISP_E_BADCALLEE, "DispCallFunc wrong error %x\n", res ); }
However, the stdcall tests have absolutely nothing to do with whether or not it's win64, but rather if the ABI itself supports stdcall or not. In my opinion, I believe there should be a constant defined at the top according to the ABI. I *think* the only platform that supports stdcall like that is i386, so have something like:
#ifdef (__i386__) static const BOOL abi_supports_stdcall = TRUE; #else static const BOOL abi_supports_stdcall = FALSE; #endif
And then change the 'if' using it to be: if (abi_supports_stdcall) { ... }
I hadn't submitted that patch yet, since I didn't know how you wanted to address it. But, if that's an acceptable solution, I would be glad to make a patch for the test suite too.
Donna
On Tue, Oct 31, 2017, at 05:02, Martin Storsjö wrote:
On Tue, 31 Oct 2017, Alexandre Julliard wrote:
Donna Whisnant dewhisna@dewtronics.com writes:
Adds ARM ABI support to DispCallFunc() to allow IDispatch invoke calls to succeed on ARM platforms. This change specifically targets only 32-bit little-endian (ARMEL) platform CPUs. It's believed to likely be compatible with big-endian (ARMEB) platforms, but testing for that platform should be completed before enabling.
Tested on Raspbian Stretch 2017-09-07 RPi image using a Qemu systemd container to compile and run it on an x86-64 Host.. When running on Raspberry Pi hardware, a 3G/1G split kernel needs to be used for Wine to function.
It breaks the Android build:
arm-linux-androideabi-gcc -c -o typelib.o ../../../wine/dlls/oleaut32/typelib.c -I. -I../../../wine/dlls/oleaut32 \ -I../../include -I../../../wine/include -D__WINESRC__ -D_OLEAUT32_ -D_REENTRANT -fPIC -Wall -pipe \ -fno-strict-aliasing -Wdeclaration-after-statement -Wempty-body -Wignored-qualifiers \ -Wstrict-prototypes -Wtype-limits -Wunused-but-set-parameter -Wvla -Wwrite-strings -Wpointer-arith \ -Wlogical-op -gdwarf-2 -gstrict-dwarf -g -O2 -fno-diagnostics-show-caret -D__ANDROID_API__=26 -marm {standard input}: Assembler messages: {standard input}:32: Error: selected processor does not support ARM mode `vldm r3!,{s0-s15}' Makefile:516: recipe for target 'typelib.o' failed make: *** [typelib.o] Error 1
FWIW, this is the same issue as was discussed before here: https://www.winehq.org/pipermail/wine-devel/2017-September/118872.html
// Martin