Req #78270 [PATCH]: Usage of __vectorcall convention with FFI

Edit report at https://bugs.php.net/bug.php?id=78270&edit=1 ID: 78270 Patch added by: cmb@php.net Reported by: lisachenko dot it at gmail dot com Summary: Usage of __vectorcall convention with FFI Status: Open Type: Feature/Change Request Package: Unknown/Other Function Operating System: Windows x64 PHP Version: 7.4.0alpha2 Block user comment: N Private report: N New Comment: The following patch has been added/updated: Patch Name: override-zend-fastcall Revision: 1563792985 URL: https://bugs.php.net/patch-display.php?bug=78270&patch=override-zend-fastcall&revision=1563792985 Previous Comments: ------------------------------------------------------------------------ [2019-07-21 04:22:04] php-bugs at lists dot php dot net No feedback was provided. The bug is being suspended because we assume that you are no longer experiencing the problem. If this is not the case and you are able to provide the information that was requested earlier, please do so and change the status of the bug back to "Re-Opened". Thank you. ------------------------------------------------------------------------ [2019-07-11 14:53:28] lisachenko dot it at gmail dot com I've checked the source code of libffi. Zero lines about vectorcall, so unlikely that this convention is supported right now. x32 was typo, there should be "x86" of course. You can start debug this with simple attempt to import zend_atoi function under Windows platform which is declared as following: ZEND_API int ZEND_FASTCALL zend_atoi(const char *str, size_t str_len); Minimal reproduced case: <?php $vectorcallBug = FFI::cdef("extern int zend_atoi(const char *str, size_t str_len);", 'php7.dll'); $vectorcallBug->zend_atoi(); // Good if we can see an exception about invalid argument number But now we can get only this: Fatal error: Uncaught FFI\Exception: Failed resolving C function 'zend_atoi' ------------------------------------------------------------------------ [2019-07-11 01:35:11] ab@php.net Thanks for the report. The vectorcall calling convention for 64-bit is the analogue of fastcall on 32-bit. 64-bit supports a very few calling conventions, vectorcall is the most advanced one compared to both default 64-bit and to fastcall. The latest libffi has been released quite a long ago, it might make sense to check whether the latest dev supports vectorcall. It would be also the preferable way, as vectorcall is per se a far better option than the default x64 calling convention. Performance improvements was the reason switching to it back then, and removing it just out of hand without a good QA would be IMO a no go. On a case-by-case base, one could check where such a switch wouldn't impact, but for sure not just a blanket removal. Also not sure the note about x32, did you mean x86? Also, could you please put a piece of code one could start with? Perhaps a list of functions where the issue was met. Thanks. ------------------------------------------------------------------------ [2019-07-10 13:37:41] lisachenko dot it at gmail dot com Description: ------------ I'm trying to import AST internal PHP functions with FFI, but for Windows platform this brings a lot of pain, because __vectorcall convention is used. It was introduced in https://github.com/php/php-src/commit/3b6cd5fe4ce81d3d219887339f3915140214708c Unfortunately, libffi doesn't support vectorcall convention, thus symbol could not be imported properly with FFI. Is it possible to remove such specific calling convention, used for ZEND_FASTCALL macros for 7.4.0 and just switch to traditional one: __fastcall for x32. For x64 platform Expected result: ---------------- All exported PHP functions don't use vectorcall convention anymore. Actual result: -------------- Some PHP functions are exported as vectorcall-functions (have double @@ at the end with number of additional bytes), for example, "zend_ast_evaluate@@24" and could not be imported with FFI under Windows platform. ------------------------------------------------------------------------ -- Edit this bug report at https://bugs.php.net/bug.php?id=78270&edit=1