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.
I've fixed my Android toolchain and added a configure check to require floating point support, so hopefully this will work now.
Is that the best long-term solution? Wouldn't there be users who might wish to use Wine with soft-FP on ARM? I just dug out my old Android NDK toolchain (one downloaded from android.com prebuilt) from the last time I was doing Android development (about four years ago) and dumped the compiler's built-in defines, and confirmed that it was built for soft-FP, at least as the default. So I could envision someone wanting Wine to work with soft-FP.
One example that comes to mind is someone writing an app where they wish to make certain that data round-trips scaling calculations across multiple platforms. For hard-FP, that's usually done with setting the FP coprocessor configuration for specific modes, such as how denormalization is handled and/or how infinity is processed. But, when interacting with a compound software application (where there's a main application with plug-in components coming from separate design groups), there are cases when changing the coprocessor settings would adversely affect the parent application, and so using soft-FP is often the solution.
In fact, the application I've been working on that prompted my adding this function for ARM to Wine in the first place may end up being such an application (depends on how easily our floating-point janitor functions port to ARM). So it seems like the best general solution is to have two sets of functions, one for hard-FP and one for soft-FP.
I would have to research the soft-FP ABI details to confirm, but I believe for the soft-FP path it's just a matter of rolling the VT_R4 and VT_R8 cases in with the VT_I4 and VT_I8, respectively, in DispCallFunc(), drop the floats from the reg_args structure passed to the assembly function, and drop the 'vldm' instruction in the assembly code.
It would just be a matter of deciding if the code looks cleaner to keep the two totally separate or to just have a few special-cases for the soft-FP mode. If you'd like, I can write the soft-FP case and submit it, and that would keep from backing us in a corner of only supporting hard-FP with Wine. It could allow Wine to be used on many other ARM type devices out there.
Donna