You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@apr.apache.org by Aaron Bannert <aa...@clove.org> on 2002/04/26 02:19:16 UTC
atomics on solaris producing non-portable binaries
I've just come across a serious problem in the atomics autoconf
code. Since we are detecting which sparc architecture the build is
running on, and passing architecture-specific flags to the assembler,
we are producing binaries that aren't backward-compatible.
For example, I have a build of APR from an Ultra5 running Solaris 5.6
that produces sparcv8plus binaries. These binaries do not work on an
older SparcStation5 machine that is running Solaris 5.7.
Is there still a way we can (automatically) produce atomics code while
preserving backward compatibility? At least we should be portable based
on OS rev (eg. Solaris 5.6 builds of APR should run on every 5.6
machine out there).
-aaron
Re: atomics on solaris producing non-portable binaries
Posted by Justin Erenkrantz <je...@apache.org>.
On Thu, Apr 25, 2002 at 06:56:13PM -0700, Aaron Bannert wrote:
> On Thu, Apr 25, 2002 at 05:54:35PM -0700, Justin Erenkrantz wrote:
> > How about just using the generic code for these types of situations?
> > Perhaps we need an --disable-atomic-asm flag that forces the generic
> > code to be used instead of assembly code? -- justin
>
> Unfortunately that still won't allow our binaries to be portable on
> Solaris/Sparc, even within the same version of Solaris.
Why not? It'd just be using C primatives - there would be no
assembly to make it non-portable. -- justin
Re: atomics on solaris producing non-portable binaries
Posted by Aaron Bannert <aa...@clove.org>.
On Thu, Apr 25, 2002 at 05:54:35PM -0700, Justin Erenkrantz wrote:
> How about just using the generic code for these types of situations?
> Perhaps we need an --disable-atomic-asm flag that forces the generic
> code to be used instead of assembly code? -- justin
Unfortunately that still won't allow our binaries to be portable on
Solaris/Sparc, even within the same version of Solaris.
-aaron
Re: atomics on solaris producing non-portable binaries
Posted by Justin Erenkrantz <je...@apache.org>.
On Thu, Apr 25, 2002 at 05:19:16PM -0700, Aaron Bannert wrote:
> I've just come across a serious problem in the atomics autoconf
> code. Since we are detecting which sparc architecture the build is
> running on, and passing architecture-specific flags to the assembler,
> we are producing binaries that aren't backward-compatible.
>
> For example, I have a build of APR from an Ultra5 running Solaris 5.6
> that produces sparcv8plus binaries. These binaries do not work on an
> older SparcStation5 machine that is running Solaris 5.7.
>
> Is there still a way we can (automatically) produce atomics code while
> preserving backward compatibility? At least we should be portable based
> on OS rev (eg. Solaris 5.6 builds of APR should run on every 5.6
> machine out there).
How about just using the generic code for these types of situations?
Perhaps we need an --disable-atomic-asm flag that forces the generic
code to be used instead of assembly code? -- justin
Re: atomics on solaris producing non-portable binaries
Posted by jean-frederic clere <jf...@fujitsu-siemens.com>.
Jeff Trawick wrote:
> Aaron Bannert <aa...@clove.org> writes:
>
>
>>For example, I have a build of APR from an Ultra5 running Solaris 5.6
>>that produces sparcv8plus binaries. These binaries do not work on an
>>older SparcStation5 machine that is running Solaris 5.7.
>
>
> I'm glad somebody else noticed this :) I had the fear that somebody
> would put the atomic stuff all over Apache and then our build machine
> for Solaris binaries caught on fire and had to be replaced with
> something new and then we had screaming customers as soon as they
> picked up a new build.
>
>
>>Is there still a way we can (automatically) produce atomics code while
>>preserving backward compatibility? At least we should be portable based
>>on OS rev (eg. Solaris 5.6 builds of APR should run on every 5.6
>>machine out there).
>
>
> I don't know about automatic, but maybe some flag is needed to specify
> the architecture level we should enable?
>
> So if you want a binary build for 2.6 and above, on sparc7 and above,
> then you build on 2.6 and pass the --with-cpu=sparc7 flag to configure
> and it doesn't matter if you're building on the latest and greatest
> CPU. Is that workable? I guess if you want brain-dead atomic stuff
> you could say --with-cpu=generic.
I prefer the --with-cpu and suggest to default to generic.
>
Re: atomics on solaris producing non-portable binaries
Posted by Brian Pane <bp...@pacbell.net>.
Jeff Trawick wrote:
>Aaron Bannert <aa...@clove.org> writes:
>
>>For example, I have a build of APR from an Ultra5 running Solaris 5.6
>>that produces sparcv8plus binaries. These binaries do not work on an
>>older SparcStation5 machine that is running Solaris 5.7.
>>
>
>I'm glad somebody else noticed this :) I had the fear that somebody
>would put the atomic stuff all over Apache and then our build machine
>for Solaris binaries caught on fire and had to be replaced with
>something new and then we had screaming customers as soon as they
>picked up a new build.
>
I was thinking about this recently (while trying to figure out
how to convert the CAS on Solaris/Sparc to a #defined asm directive
so that we could inline it)...
If we can rely on libapr.so being a shared lib, then the solution may
be to just provide different builds of libapr for different CPU iterations--
e.g., on Sparcs, we'd basically need "UltraSparc" and "pre-Ultra" versions.
However, that would rob us of the ability to inline the CAS. To me,
that's somewhat of a problem, because one common use of CAS is for
spin locks. Adding the overhead of a function call increases the time
spent in the code path where the spin lock is vulnerable to a race
condition, and thus the probability that the spin lock will have to
retry.
--Brian
Re: atomics on solaris producing non-portable binaries
Posted by Dale Ghent <da...@elemental.org>.
On Thu, 25 Apr 2002, Aaron Bannert wrote:
| I was thinking that we could determine what the lowest-supported
| architecture was for each version of Solaris, and that would be the
| ISA that would be passed as -xarch. (Having an override would be fine,
| but I'm wholly against the building of non-portable binaries by default.)
|
| I have no idea how to determine what the least supported arch is for
| each version of Solaris, though.
Then you are looking for SPARC v8. -mv8 on your gcc compiler. This would
not give you cas though. That's a V8+ instruction.
/dale
Re: atomics on solaris producing non-portable binaries
Posted by Aaron Bannert <aa...@clove.org>.
On Thu, Apr 25, 2002 at 10:14:19PM -0400, Jeff Trawick wrote:
> > Is there still a way we can (automatically) produce atomics code while
> > preserving backward compatibility? At least we should be portable based
> > on OS rev (eg. Solaris 5.6 builds of APR should run on every 5.6
> > machine out there).
>
> I don't know about automatic, but maybe some flag is needed to specify
> the architecture level we should enable?
I was thinking that we could determine what the lowest-supported
architecture was for each version of Solaris, and that would be the
ISA that would be passed as -xarch. (Having an override would be fine,
but I'm wholly against the building of non-portable binaries by default.)
I have no idea how to determine what the least supported arch is for
each version of Solaris, though.
-aaron
Re: atomics on solaris producing non-portable binaries
Posted by Jeff Trawick <tr...@attglobal.net>.
Aaron Bannert <aa...@clove.org> writes:
> For example, I have a build of APR from an Ultra5 running Solaris 5.6
> that produces sparcv8plus binaries. These binaries do not work on an
> older SparcStation5 machine that is running Solaris 5.7.
I'm glad somebody else noticed this :) I had the fear that somebody
would put the atomic stuff all over Apache and then our build machine
for Solaris binaries caught on fire and had to be replaced with
something new and then we had screaming customers as soon as they
picked up a new build.
> Is there still a way we can (automatically) produce atomics code while
> preserving backward compatibility? At least we should be portable based
> on OS rev (eg. Solaris 5.6 builds of APR should run on every 5.6
> machine out there).
I don't know about automatic, but maybe some flag is needed to specify
the architecture level we should enable?
So if you want a binary build for 2.6 and above, on sparc7 and above,
then you build on 2.6 and pass the --with-cpu=sparc7 flag to configure
and it doesn't matter if you're building on the latest and greatest
CPU. Is that workable? I guess if you want brain-dead atomic stuff
you could say --with-cpu=generic.
--
Jeff Trawick | trawick@attglobal.net
Born in Roswell... married an alien...
Re: atomics on solaris producing non-portable binaries
Posted by Dale Ghent <da...@elemental.org>.
On Thu, 25 Apr 2002, Aaron Bannert wrote:
| I've just come across a serious problem in the atomics autoconf
| code. Since we are detecting which sparc architecture the build is
| running on, and passing architecture-specific flags to the assembler,
| we are producing binaries that aren't backward-compatible.
|
| For example, I have a build of APR from an Ultra5 running Solaris 5.6
| that produces sparcv8plus binaries. These binaries do not work on an
| older SparcStation5 machine that is running Solaris 5.7.
|
| Is there still a way we can (automatically) produce atomics code while
| preserving backward compatibility? At least we should be portable based
| on OS rev (eg. Solaris 5.6 builds of APR should run on every 5.6
| machine out there).
cas is a sparc v8plus instruction, which is supported on UltraSPARC-I and
better chips.
Obviously this would fail on a non-ultrasparc system. Noway around it
unless atomics is disabled.
/dale