Bug #69693 [Opn->Fbk]: Compatibility with x32 ABI

Edit report at https://bugs.php.net/bug.php?id=69693&edit=1 ID: 69693 Updated by: cmb@php.net Reported by: bugs at tmarques dot com Summary: Compatibility with x32 ABI -Status: Open +Status: Feedback Type: Bug Package: *General Issues Operating System: Linux x32 PHP Version: 5.6.23 -Assigned To: +Assigned To: cmb Block user comment: N Private report: N New Comment: What is the status of the actively supported PHP versions[1] regarding x32 ABI? If anything would need to be fixed, I suggest you submit a pull request[2]. [1] <https://www.php.net/supported-versions.php> [2] <https://github.com/php/php-src/pulls> Previous Comments: ------------------------------------------------------------------------ [2016-07-12 23:12:03] bugs at tmarques dot com Hey there, Been trying x32 on PHP 7 and it has various bugs that keep it from working. I've been trying to fix some stuff but still have problems with PHAR during compilation, which seems to stem from a memcpy(). Would it be possible to merge this updated patch below? I backported some changes from the assembly in PHP 7 that seems to fix a movb that was malformed. It works on both 5.5.37 and 5.6.23. There are some 32-bit tests that fail because time values are expected to overflow and don't, which haven't tracked but may be related to x32 having 64-bit time values. https://github.com/tmarques/overlay_x32-abi/raw/master/dev-lang/php/files/zend_operators_x32-5.patch ------------------------------------------------------------------------ [2015-10-17 14:14:02] bugs at tmarques dot com Hey there, Had been looking at the date bugs I posted before from the test suite but everything seemed fine where I looked. Today I tried the zend operators patch on 5.6.13 and those are gone. Tests below configured with: ===================================================================== FAILED TEST SUMMARY --------------------------------------------------------------------- Bug #53437 DateInterval unserialize bad data, 32 bit [ext/date/tests/bug53437_var3.phpt] Bug #64146 (serialize incorrectly saving objects when they are cloned) [ext/standard/tests/serialize/bug64146.phpt] ===================================================================== WARNED TEST SUMMARY --------------------------------------------------------------------- Bug #70172 - Use After Free Vulnerability in unserialize() [ext/standard/tests/serialize/bug70172.phpt] (warn: XFAIL section but test passes) ===================================================================== Compiled on i686 to check for differences and the i686 versions shows one more failed test but is otherwise the same. I imagine this is due to some fix related to x86-64. ===================================================================== Bug #41655 (open_basedir bypass via glob()) 1/2 [ext/standard/tests/file/bug41655_1.phpt] chroot() [ext/standard/tests/file/chroot_001.phpt] Test glob() function: ensure no platform difference, variation 3 [ext/standard/tests/file/glob_variation5.phpt] ===================================================================== At this time, the zend_operators patch seems to work for these versions, so could it possibly be merged? Glad to hear PHP7 is looking good on x32! As for the integer size, it would be better to be 32bit to be consistent with C and be able to make use of both of 32 and 64bit registers, which is one of the performance benefits. My understanding is that PHP only supports one integer size, so being 64bit is probably better if the programmer can't choose. ------------------------------------------------------------------------ [2015-05-25 09:01:46] nikic@php.net For the record, PHP 7 is now mostly working on x32 as well. I've landed some tweaks in https://github.com/php/php-src/commit/f3dde29394831c59fc927bd5e7a7800a3fbe8519 which make nearly all tests pass - there's two or three failures left due to wrong size_t/zend_long usage resulting in overflows. I went for making PHP integers 64bit - this integrates very nicely with how zend_long is currently used (all our assembly is still correct) and I think this is what PHP programmers would want to have. But not totally sure if this is the right choice. ------------------------------------------------------------------------ [2015-05-25 01:32:12] bugs at tmarques dot com Forgot to mention I'll be looking at the rest of the tests to see if I can fix them. Pointers to the Date issues would be useful. ------------------------------------------------------------------------ [2015-05-25 01:27:28] bugs at tmarques dot com Managed to fix some stuff, though they're mostly hacks to always run i386 code. Current problem is most of the Zend operators are passing 64bit instructions to x32 PHP, so I just #if'd them to add ILP32 checks to the i386 assembly instead. I think this is mostly correct (not optimized) but x86-64 assembly has the same issue with these x32 changes: it is still using x87 instead of the faster SSE2, as it should on x86-64 capable CPUs. From looking at the current code, I didn't understand why the FPU is being used to calculate integer operations (this shouldn't be faster). I also think there might be problems with the 'safe_address' function in 'Zend/zend_alloc.c', as it has LP_SUFF defined for the 'mul' instruction, as it should, but uses both 'add/adc'. My understanding from the manuals is that this is correct if the operands to the instruction are 32bit for x32, then all will be ok, while 64bit operands will execute as 64bit. Still, if this is a mixup of AT&T and Intel syntax for opcodes, it should probably be unified and checked for correct word size on the parameters. Below are the results of 'make test' before and after the patch submitted, which shows no regressions. The test case I submitted also passes now. ===================================================================== FAILED TEST SUMMARY --------------------------------------------------------------------- Bug #24054 (Assignment operator *= broken) [tests/lang/bug24054.phpt] Test >= operator : max int 32bit range [tests/lang/operators/operator_gt_or_equal_variation.phpt] Test > operator : max int 32bit range [tests/lang/operators/operator_gt_variation.phpt] Test <= operator : max int 32bit range [tests/lang/operators/operator_lt_or_equal_variation.phpt] Test < operator : max int 32bit range [tests/lang/operators/operator_lt_variation.phpt] Bug #45877 (Array key '2147483647' left as string) [Zend/tests/bug45877.phpt] decrementing different variables [Zend/tests/decrement_001.phpt] incrementing different variables [Zend/tests/increment_001.phpt] Bug #41523 (strtotime('0000-00-00 00:00:00') is parsed as 1999-11-30) (32 bit) [ext/date/tests/bug41523.phpt] Test getdate() function : usage variation - Passing high positive and negative float values to timestamp. [ext/date/tests/getdate_variation7.phpt] Test localtime() function : usage variation - Passing higher positive and negetive float values to timestamp. [ext/date/tests/localtime_variation3.phpt] Test array_sum() [ext/standard/tests/array/array_sum.phpt] Bug #65304 (Use of max int in array_sum) [ext/standard/tests/array/bug65304.phpt] Simple math tests [ext/standard/tests/math/abs.phpt] Various pow() tests [ext/standard/tests/math/pow.phpt] Simple math tests [ext/standard/tests/math/round.phpt] Bug #64146 (serialize incorrectly saving objects when they are cloned) [ext/standard/tests/serialize/bug64146.phpt] ===================================================================== Patched: ===================================================================== FAILED TEST SUMMARY --------------------------------------------------------------------- Bug #41523 (strtotime('0000-00-00 00:00:00') is parsed as 1999-11-30) (32 bit) [ext/date/tests/bug41523.phpt] Test getdate() function : usage variation - Passing high positive and negative float values to timestamp. [ext/date/tests/getdate_variation7.phpt] Test localtime() function : usage variation - Passing higher positive and negetive float values to timestamp. [ext/date/tests/localtime_variation3.phpt] Bug #64146 (serialize incorrectly saving objects when they are cloned) [ext/standard/tests/serialize/bug64146.phpt] ===================================================================== ------------------------------------------------------------------------ The remainder of the comments for this report are too long. To view the rest of the comments, please view the bug report online at https://bugs.php.net/bug.php?id=69693 -- Edit this bug report at https://bugs.php.net/bug.php?id=69693&edit=1