Edit report at https://bugs.php.net/bug.php?id=60925&edit=1
ID: 60925
Updated by: cmb@php.net
Reported by: tg at debian dot org
Summary: fpm_atomic.h says unknown processor (m68k)
-Status: Analyzed
+Status: Feedback
Type: Bug
Package: FPM related
Operating System: Linux
PHP Version: 5.4
-Assigned To:
+Assigned To: cmb
Block user comment: N
Private report: N
New Comment:
Has this issue been resolved in the meantime?
Previous Comments:
------------------------------------------------------------------------
[2012-04-16 18:31:28] tg at debian dot org
Make of this patch what you want. Iâve not gotten anything from the Linux/m68k porters other
than âwhat do you do if the syscall does not exist?â with no solution. (On the other hand,
it exists with every Linux kernel from 2.6.34 onwards or Debian 2.6.32; and older systems wonât
support the last few eglibc major releases anyway, so chances are low someoneâs trying PHP on
such systems. And the patch keeps the #error for non-Linux systems.)
------------------------------------------------------------------------
[2012-03-12 23:31:51] tg at debian dot org
Iâve built 5.4.0 with a small patch. Weâre working on getting it usable for upstream
inclusion. On Linux/m68k, one uses a syscall for compare-and-swap 32 bit, as some CPUs do not
support the machine instruction and probing for it is too tricky in user space. The syscall was
introduced along with TLS support, now we probably need to safeguard this from being compiled on
âtoo oldâ Linux systems. The patch doesnât address nÅn-Linux m68k, as those are
different beasts, and see above. (The ColdFire does not support the instruction, and Linux and MiNT
may very well both run on one with MMU, soonish.)
------------------------------------------------------------------------
[2012-02-02 20:11:39] tg at debian dot org
OK; in the meantime Iâll try building without FPM, to see whether there are any other lurking
issues on m68k. Thanks for the help with this.
------------------------------------------------------------------------
[2012-01-31 00:50:00] aharvey@php.net
Thanks again. It's been good to triage this down. :)
I'll let Jérôme figure out what he wants to do here, since he's the FPM
maintainer. I think your list of options pretty much covers it.
------------------------------------------------------------------------
[2012-01-31 00:39:53] tg at debian dot org
Heh, your comment made me go and read the old changelogs
of the Debian package on a guess, and I guessed right:
php5 (5.3.5-1) unstable; urgency=low
* Build the FPM SAPI (Closes: #603174)
So this was simply never built before. Now there are two
possibilities, disable FPM on m68k (unless gcc-4.7 or up
is used) or ask the m68k porters for an implementation
of the atomic things. I think. If youâve got a better
idea, do tell.
By the way, thereâs libatomic-ops-dev, which contains a
number of atomic primitives and composed operations on a
number of data types (but the catch is, youâve got to use
the data types of libatomic-ops-dev, not e.g. like mesa
have a function atomic_dec which is passed an int32_t*
so itâs not a plug-in replacement. That might be more
interesting than hacking in m68k support now, and support
for $next_arch laterâ¦
m68k atomic operations apparently have another twist: the
compare-and-swap operation only exists on some processors,
and not in the Coldfire line, so the Linux kernel got a
syscall now to ensure atomicity. GCC 4.7 uses the syscall;
most âinlinedâ application code doesnâtâ¦
------------------------------------------------------------------------
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=60925
--
Edit this bug report at https://bugs.php.net/bug.php?id=60925&edit=1