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
Block user comment: N
Private report: N
New Comment:
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.)
Previous Comments:
------------------------------------------------------------------------
[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.
------------------------------------------------------------------------
[2012-01-30 16:52:13] tg at debian dot org
configure:12302: checking if gcc supports __sync_bool_compare_and_swap
configure:12319: m68k-linux-gnu-gcc -o conftest -O2 -Wall -fsigned-char
-fno-strict-aliasing -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -gstabs
-fvisibility=hidden conftest.c -lrt >&5
/tmp/ccmCFUbp.o: In function `main':
conftest.c:48: undefined reference to `__sync_bool_compare_and_swap_4'
conftest.c:49: undefined reference to `__sync_add_and_fetch_4'
collect2: ld returned 1 exit status
configure:12319: $? = 1
configure: failed program was:
| /* confdefs.h */
| #define PACKAGE_NAME ""
| #define PACKAGE_TARNAME ""
| #define PACKAGE_VERSION ""
| #define PACKAGE_STRING ""
| #define PACKAGE_BUGREPORT ""
| #define PACKAGE_URL ""
| #define STDC_HEADERS 1
| #define HAVE_SYS_TYPES_H 1
| #define HAVE_SYS_STAT_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_STRING_H 1
| #define HAVE_MEMORY_H 1
| #define HAVE_STRINGS_H 1
| #define HAVE_INTTYPES_H 1
| #define HAVE_STDINT_H 1
| #define HAVE_UNISTD_H 1
| #define __EXTENSIONS__ 1
| #define _ALL_SOURCE 1
| #define _GNU_SOURCE 1
| #define _POSIX_PTHREAD_SEMANTICS 1
| #define _TANDEM_SOURCE 1
| #define HAVE_DEV_URANDOM 1
| #define HAVE_SETENV 1
| #define HAVE_CLEARENV 1
| #define HAVE_ERRNO_H 1
| #define HAVE_FCNTL_H 1
| #define HAVE_STDIO_H 1
| #define HAVE_STDLIB_H 1
| #define HAVE_UNISTD_H 1
| #define HAVE_SYS_UIO_H 1
| #define HAVE_SYS_SELECT_H 1
| #define HAVE_SYS_SOCKET_H 1
| #define HAVE_SYS_TIME_H 1
| #define HAVE_ARPA_INET_H 1
| #define HAVE_NETINET_IN_H 1
| #define HAVE_PRCTL 1
| #define HAVE_CLOCK_GETTIME 1
| #define HAVE_PTRACE 1
| #define PROC_MEM_FILE "mem"
| /* end confdefs.h. */
|
| int
| main ()
| {
|
| int variable = 1;
| return (__sync_bool_compare_and_swap(&variable, 1, 2)
| && __sync_add_and_fetch(&variable, 1)) ? 1 : 0;
|
| ;
| return 0;
| }
configure:12329: result: no
------------------------------------------------------------------------
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
