[v3] oleaut32: Add ARM support to DispCallFunc().

Donna Whisnant dewhisna at dewtronics.com
Tue Oct 31 09:01:13 CDT 2017


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 at 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



More information about the wine-devel mailing list