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:
First of all: thanks for not taking my rant badly :)
Of course I can run this code and, well "test" it. I would have been
happier
however if someone besides me had looked over the code and said "yes,
that looks
like it could work" ;)
Right now it *is* running on two ReadyNAS (Sparc) boxes as well as on my
SunFire
280R. It doesn't segfault which to me is a good sign and it's producing
normale
output from the small test scripts I have run. Haven't done extensive
testing so
far but will try running Wordpress and Drupal in the next couple of
days. If
there's any special test you'd like to see me run against the patched
version of
PHP, let me know.
Previous Comments:
------------------------------------------------------------------------
[2010-11-17 01:18:49] [email protected]
@stefan at whocares dot de
Did you run your patch on a ReadyNAS box ? If you test it and tell us it
works,
there is not reason not to integrate it. As far as I know, it's not been
tested
but for compilation only.
We don't want to leave someone behind, but as pierre told you there is
priorities.
We'll be glad if you help us.
------------------------------------------------------------------------
[2010-11-17 01:16:15] [email protected]
and I was wiling to write arch, not OS....
------------------------------------------------------------------------
[2010-11-17 01:15:26] [email protected]
It was not badly meant, only trying to show you alternative.
I can't know nor judge the reason why you need v8 support, but have been
there many times in the past for my numerous projects.
We have to make decisions about which platforms we can support, and also
which we stop to support. There is nothing personal or aggressive in our
replies, only trying to explain the status and the reasoning behind it.
Sorry if you took it so badly, that's not the aim of our comments, or
mines in particular.
------------------------------------------------------------------------
[2010-11-17 01:09:51] stefan at whocares dot de
@[email protected]
Did it ever occur to you that I found this bug/problem because I
*specifically
wanted to use FPM* in the first place? Had I wanted to use FastCGI I'd
have
certainly done so. Seeing that there already was a solution for Sparc v9
I
thought there might be interest in a solution that would allow PHP to
run on
older machines.
Hardware that maybe you're laughing about. But hardware that's still in
fairly
wide use. And, come to think of it, hardware that may also be the only
hardware
people in poorer countries than the one you're obviously living in are
able to
get their hands on. So I first asked and then got my hands dirty and
even
provided a possible solution - and one that could be easily implemented,
too.
And what for? Only to get ignorance and witty remarks in return. Well, I
almost
forgot that the PHP project has such a bad reputation when it comes to
bugs and
patches. Thanks for reminding me why. Now you can safely go back to your
ivory
tower and think about supporting next decade's hardware only. For my
part, I
promise to keep any bugs/problems in PHP I may find in the future to
myself and
will do the same for any patches I may come up with.
Btw: the boxes I'm talking about are running Linux (which you could have
seen by
looking at the "OS:" tag) and I really have no idea why you'd call that
a "soon
to be dead OS". If you have a problem understanding the difference
between a CPU
and an OS, may I ask what exactly makes you think you can give some
valuable
input here? As for the "cruelly needed developers" you mention: I don't
see why
you should need those as long as the community comes up with patches you
could
use. Ok, if you keep driving away people like this, I start to have an
idea as
to why ;)
------------------------------------------------------------------------
[2010-11-17 00:24:30] stefan at whocares dot de
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.
------------------------------------------------------------------------
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
