Edit report at http://bugs.php.net/bug.php?id=53310&edit=1
ID: 53310
User updated by: stefan at whocares dot de
Reported by: stefan at whocares dot de
Summary: fpm_atomic.h uses SPARC v9 only code, doesn't work
on v8
Status: Wont fix
Type: Feature/Change Request
Package: FPM related
Operating System: Linux (Debian for Sparc)
PHP Version: 5.3.3
Assigned To: fat
Block user comment: N
Private report: N
New Comment:
As you may have read in my initial post, the compiler I (have to) use is
gcc
3.3.5 which falls a bit short of 4.1 ;) Also, you may want to read the
backend/port/tas/solaris_sparc.s file from the official PostgreSQL
sources:
! "cas" only works on sparcv9 and sparcv8plus chips, and
! requies a compiler targeting these CPUs. It will fail
! on a compiler targeting sparcv8, and of course will not
! be understood by a sparcv8 CPU. gcc continues to use
! "ldstub" because it targets sparcv7.
There they work around this by using a condition (for the SUN compiler)
like
this:
#if defined(__sparcv9) || defined(__sparcv8plus)
cas [%o0],%o2,%o1
#else
ldstub [%o0],%o1
#endif
and in their actual generic lock implementation
(src/include/storage/s_lock.h)
the code is this:
#if defined(__sparc__) /* Sparc */
#define HAS_TEST_AND_SET
typedef unsigned char slock_t;
#define TAS(lock) tas(lock)
static __inline__ int
tas(volatile slock_t *lock)
{
register slock_t _res;
/*
* See comment in /pg/backend/port/tas/solaris_sparc.s for
why this
* uses "ldstub", and that file uses "cas". gcc currently
generates
* sparcv7-targeted binaries, so "cas" use isn't possible.
*/
__asm__ __volatile__(
" ldstub [%2], %0 \n"
: "=r"(_res), "+m"(*lock)
: "r"(lock)
: "memory");
return (int) _res;
}
#endif /* __sparc__ */
Now my general idea was that if there's a reason for PostgreSQL to keep
that
code around, there might be a reason for PHP to do so as well. Obviously
I was
wrong there.
I also do not see the real advantage of 'cas' over 'ldstub' in the
current
scenario since both are atomic, both are supported (ldstub even on v7)
and both
do the job perfectly well.
Previous Comments:
------------------------------------------------------------------------
[2010-11-17 00:22:59] paj...@php.net
And you can still use FastCGI, btw. FPM is fairly new, and if new SAPIs
have to support soon to be dead OSes, then we will cruelly need more
developers to maintain everything :)
------------------------------------------------------------------------
[2010-11-17 00:03:57] f...@php.net
you should be able to compile with a gcc version which provides the
__sync_bool_compare_and_swap builtin function (>= 4.1).
It's supported by FPM. If with this version of GCC FPM is not able to be
compiled,
there is a bug in FPM. We'll take care of it.
It this a reasonable solution ?
------------------------------------------------------------------------
[2010-11-16 23:52:42] stefan at whocares dot de
Of course you may ask: because I'm porting PHP to the ReadyNAS platform
which
happens to use a SPARC v8 compatible CPU and thus *needs* the v8
instruction set.
Seeing that you've already made up your mind though, so I guess there's
nothing
more to add here. Makes me wonder why I can't get a response in > 24
hours as to
my patch but you can't wait for me to answer for like 4 hours.
------------------------------------------------------------------------
[2010-11-16 23:05:04] f...@php.net
we've decided sparc < v9 won't be supported. I've just updated the
source code to
warn specificaly about this.
------------------------------------------------------------------------
[2010-11-16 23:02:38] f...@php.net
Automatic comment from SVN on behalf of fat
Revision: http://svn.php.net/viewvc/?view=revision&revision=305417
Log: - Fixed #53310 (sparc < v9 won't is not supported)
------------------------------------------------------------------------
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
http://bugs.php.net/bug.php?id=53310
--
Edit this bug report at http://bugs.php.net/bug.php?id=53310&edit=1
