Bug #76654 [ReO]: Build failure on Mac OS X on 32-bit Intel

From: Date: Sat, 08 Dec 2018 15:58:22 +0000
Subject: Bug #76654 [ReO]: Build failure on Mac OS X on 32-bit Intel
References: 1  Groups: php.bugs 
Request: Send a blank email to php-bugs+get-218342@lists.php.net to get a copy of this message
Edit report at https://bugs.php.net/bug.php?id=76654&edit=1 ID: 76654 User updated by: php-bugs-2018 at ryandesign dot com Reported by: php-bugs-2018 at ryandesign dot com Summary: Build failure on Mac OS X on 32-bit Intel Status: Re-Opened Type: Bug Package: Compile Failure Operating System: Mac OS X 10.6.8 PHP Version: 7.3.0RC5 Block user comment: N Private report: N New Comment: I've submitted the patch as a PR: https://github.com/php/php-src/pull/3704 Previous Comments: ------------------------------------------------------------------------ [2018-11-15 09:21:42] php-bugs-2018 at ryandesign dot com I revised the patch to only preserve %ebx when building with PIC, after looking at what libwebp did: https://github.com/webmproject/libwebp/blob/a4399721759f183bcc7c1d69c2f7eba1ceb8d1a2/src/dsp/cpu.c#L30 I see that their implementation for preserving %ebx is one instruction shorter... not sure if it's worth changing it though. If you'd rather have this patch as a PR let me know. ------------------------------------------------------------------------ [2018-11-15 07:12:01] php-bugs-2018 at ryandesign dot com I've attached a patch that compiles for me, on 32-bit Mac OS X 10.6. What I've learned is that gcc 4.2 (at least the Apple-modified version shipped in old Xcode) uses position-independent code (PIC) by default, and that on i386 this compiler uses the %ebx register to store the PIC global offset table, but the cpuid opcode overwrites %ebx, hence the error. So %ebx needs to be preserved before calling cpuid and restored afterward. I've modeled my patch on the method used by cpuid.h from Xcode 5.1.1 on OS X 10.8, which is as follows: /* PIC on i386 uses %ebx, so preserve it. */ #if __i386__ #define __cpuid(__level, __eax, __ebx, __ecx, __edx) \ __asm(" pushl %%ebx\n" \ " cpuid\n" \ " mov %%ebx,%1\n" \ " popl %%ebx" \ : "=a"(__eax), "=r" (__ebx), "=c"(__ecx), "=d"(__edx) \ : "0"(__level)) #define __cpuid_count(__level, __count, __eax, __ebx, __ecx, __edx) \ __asm(" pushl %%ebx\n" \ " cpuid\n" \ " mov %%ebx,%1\n" \ " popl %%ebx" \ : "=a"(__eax), "=r" (__ebx), "=c"(__ecx), "=d"(__edx) \ : "0"(__level), "2"(__count)) #else #define __cpuid(__level, __eax, __ebx, __ecx, __edx) \ __asm("cpuid" : "=a"(__eax), "=b" (__ebx), "=c"(__ecx), "=d"(__edx) \ : "0"(__level)) #define __cpuid_count(__level, __count, __eax, __ebx, __ecx, __edx) \ __asm("cpuid" : "=a"(__eax), "=b" (__ebx), "=c"(__ecx), "=d"(__edx) \ : "0"(__level), "2"(__count)) #endif It seems that cpuid.h is closely tied to and belongs with a particular compiler. The cpuid.h from Xcode 9.4.1 on macOS 10.13 does it differently, for example, but that's for a much more recent version of clang. And since this code in PHP is only going to be used by compilers that don't provide a cpuid.h, maybe using this old implementation is the correct thing to do. With my patch it compiles, but I don't know if the result is correct. I don't know how this command is used within PHP. Is there a PHP command I should run, or a particular test in the test suite that I should look at, to verify it's working right? ------------------------------------------------------------------------ [2018-09-30 04:00:08] php-bugs-2018 at ryandesign dot com Please reopen; the problem remains with 7.3.0RC2. Here is a full build log of the failure on 10.6.8 i386: https://build.macports.org/builders/ports-10.6_i386_legacy-builder/builds/49799/steps/install-port/logs/stdio For comparison, here is a build log of success on 10.6.8 x86_64: https://build.macports.org/builders/ports-10.6_x86_64_legacy-builder/builds/77655/steps/install-port/logs/stdio And a build log of success on 10.5.8 ppc: https://build.macports.org/builders/ports-10.5_ppc_legacy-builder/builds/75623/steps/install-port/logs/stdio ------------------------------------------------------------------------ [2018-08-26 17:02:12] cmb@php.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. ------------------------------------------------------------------------ [2018-07-24 09:40:56] cmb@php.net The PR has been merged; please try with a recent Git snapshot. ------------------------------------------------------------------------ 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=76654 -- Edit this bug report at https://bugs.php.net/bug.php?id=76654&edit=1

« previous php.bugs (#218342) next »