Edit report at https://bugs.php.net/bug.php?id=60925&edit=1

 ID:                 60925
 User updated by:    tg at debian dot org
 Reported by:        tg at debian dot org
 Summary:            fpm_atomic.h says unknown processor (m68k)
 Status:             Open
 Type:               Bug
 Package:            FPM related
 Operating System:   Linux
-PHP Version:        5.3.9
+PHP Version:        5.4
 Block user comment: N
 Private report:     N

 New Comment:

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.)


Previous Comments:
------------------------------------------------------------------------
[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] ahar...@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…

------------------------------------------------------------------------
[2012-01-31 00:06:52] ahar...@php.net

Ah, I didn't know that, so no, no need on the vanilla tarball front. Thanks!

The fix here would be a patch for fpm_atomic.h implementing the same atomic 
functions for m68k as the other fallback platforms in there, such as x86 and 
SPARC 
v9. I'm not actually sure why 5.3.3-7 built at all, actually -- the only patch 
it 
had over stock 5.3.3 (which had no support at all for m68k) was implementing 
support for __sync_bool_compare_and_swap() if it existed, so it should have 
failed 
with the same #error. Interesting.

------------------------------------------------------------------------


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

Reply via email to