Sun Studio on Linux spinlock patch
Hi All,
I have made PostgreSQL to compile on linux using sun studio with
spinlock support. The patch is attached. Here is the explanation of
changes I made:
I renamed the following files
solaris_x86.s
solaris_sparch.s
to
sunstudio_x86.s
sunstudio_sparch.s
because the code is used on linux as well and is not related to solaris
but sunstudio.
I added the detection of Sun Studio to configure script, changed the
template for linux, so it gives same settings for sun studio as for solaris.
Finally, I changed the #ifdef of __sun macro to __SUNPRO_C macro in
s_lock.h. Macro __sun is defined on solaris by both gcc and sun studio
and it is not defined on linux. Macro __SUNPRO_C is defined on linux as
well as solaris by sun studio and is never defined by gcc.
I tested the patch (build process & make check) without any problems on:
x86, solaris nevada build 79; gcc 3.4.3 (csl-sol210-3_4-20050802)
x86, solaris nevada build 79; sun studio 12
x86, debian etch, gcc 4.1.2 (20061115)
x86, debian etch, sun studio 12
sparc, solaris 10U3, gcc 3.4.3 (csl-sol210-3_4-branch+sol_rpath)
sparc, solaris 10U3, sun studio 12
I do not have an access to linux sparc machine.
Thanks for your comments.
Cheers
Julo
Attachments:
sunstudio_linux.difftext/x-patch; name=sunstudio_linux.diffDownload+172-87
Julius Stroffek <Julius.Stroffek@Sun.COM> writes:
I have made PostgreSQL to compile on linux using sun studio with
spinlock support. The patch is attached. Here is the explanation of
changes I made:
This patch seems broken in a number of ways. Why are you removing
-DLINUX_PROFILE, for example? Are you sure you don't need -D_GNU_SOURCE?
And why add -DSUNOS4_CC, which is a Solaris-specific define (not that
we seem to be using it anywhere anymore)? Do we really have to have a
configure-time probe to detect this particular compiler?
But I guess the *real* question is why anyone would care ... what
benefit is there to using Sun's compiler on Linux?
regards, tom lane
Tom Lane napsal(a):
But I guess the *real* question is why anyone would care ... what
benefit is there to using Sun's compiler on Linux?
There are severals benefits:
1) Sun Studio is not only compiler. It has a lot of tools like
performance analyzer/profiler, memory checker ... There are group of
people who prefers these tools.
2) Compiler generates faster code on SPARC than GCC. If somebody uses
Linux on SPARC it helps him a lot. Code is faster on x86 as well, but it
is not so significant.
See http://blogs.sun.com/tatkar/resource/SunStudio.pdf
Pages 12-13
Zdenek
Tom Lane wrote:
This patch seems broken in a number of ways. Why are you removing
-DLINUX_PROFILE, for example? Are you sure you don't need -D_GNU_SOURCE?
And why add -DSUNOS4_CC, which is a Solaris-specific define (not that
we seem to be using it anywhere anymore)? Do we really have to have a
configure-time probe to detect this particular compiler?
You are right, removing -DLINUX_PROFILE seems to break profiling
on linux when compiled with sun studio.
I am not quite sure about the desired usage of _GNU_SOURCE and SUNOS4_CC
macros.
I would not expect _GNU_SOURCE to be defined when compiling sources with
Sun Studio.
I am not quite sure why SUNOS4_CC was supposed to be defined at all for
Solaris as well.
There are already enough macros defined -- "__sun" is defined on Solaris
by both Sun
Studio and gcc and "__SUNPRO_C" is defined by Sun Studio on both Linux
and Solaris.
Should we then remove _GNU_SOURCE and SUNOS4_CC macro definitions from
the build scripts since they are not used at all in the source code?
Configure-time probe for sun studio is required to create tas.s link to
the proper
file - sunstudio_x86.s (or sunstudio_sparc.s). This is done during a run
of a configure
script based on settings for the platform. Since these settings may vary
on the same platform
based on the compiler we need to have a configure-time probe.
But I guess the *real* question is why anyone would care ... what
benefit is there to using Sun's compiler on Linux?
Some tools bundled with sun studio might be used. I personally run into this
when I wanted to debug postgres with sun studio ide and wanted to compile
it first. It is based on netbeans, written in java so it needs a big
enough memory,
however it offers a great possibility to explore postgres internals during
a query execution, etc. It is especially useful, if you do not know what
you are
interested in during a compilation. I am using this to step over join
order search
plugins. I mostly use Solaris for this but I switched to linux for a while.
I wrote a blog with more details about this.
http://blogs.sun.com/databases/entry/debugging_postgresql_backends_on_solaris
There is also a screenshot showing how it looks in action
http://mediacast.sun.com/users/%7Ejulo/media/pgss_debugging.png
Also, there was some message a while back on pgsql-bugs from Len Zaifman
requesting
this as well.
Cheers
Julo
So, is this a feature we want?
---------------------------------------------------------------------------
Julius Stroffek wrote:
Tom Lane wrote:
This patch seems broken in a number of ways. Why are you removing
-DLINUX_PROFILE, for example? Are you sure you don't need -D_GNU_SOURCE?
And why add -DSUNOS4_CC, which is a Solaris-specific define (not that
we seem to be using it anywhere anymore)? Do we really have to have a
configure-time probe to detect this particular compiler?You are right, removing -DLINUX_PROFILE seems to break profiling
on linux when compiled with sun studio.I am not quite sure about the desired usage of _GNU_SOURCE and SUNOS4_CC
macros.
I would not expect _GNU_SOURCE to be defined when compiling sources with
Sun Studio.
I am not quite sure why SUNOS4_CC was supposed to be defined at all for
Solaris as well.
There are already enough macros defined -- "__sun" is defined on Solaris
by both Sun
Studio and gcc and "__SUNPRO_C" is defined by Sun Studio on both Linux
and Solaris.Should we then remove _GNU_SOURCE and SUNOS4_CC macro definitions from
the build scripts since they are not used at all in the source code?Configure-time probe for sun studio is required to create tas.s link to
the proper
file - sunstudio_x86.s (or sunstudio_sparc.s). This is done during a run
of a configure
script based on settings for the platform. Since these settings may vary
on the same platform
based on the compiler we need to have a configure-time probe.But I guess the *real* question is why anyone would care ... what
benefit is there to using Sun's compiler on Linux?Some tools bundled with sun studio might be used. I personally run into this
when I wanted to debug postgres with sun studio ide and wanted to compile
it first. It is based on netbeans, written in java so it needs a big
enough memory,
however it offers a great possibility to explore postgres internals during
a query execution, etc. It is especially useful, if you do not know what
you are
interested in during a compilation. I am using this to step over join
order search
plugins. I mostly use Solaris for this but I switched to linux for a while.I wrote a blog with more details about this.
http://blogs.sun.com/databases/entry/debugging_postgresql_backends_on_solaris
There is also a screenshot showing how it looks in action
http://mediacast.sun.com/users/%7Ejulo/media/pgss_debugging.pngAlso, there was some message a while back on pgsql-bugs from Len Zaifman
requesting
this as well.Cheers
Julo
--
Sent via pgsql-patches mailing list (pgsql-patches@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-patches
--
Bruce Momjian <bruce@momjian.us> http://momjian.us
EnterpriseDB http://enterprisedb.com
+ If your life is a hard drive, Christ can be your backup. +