Re: solaris build problem with Sun compilers
От | Bruce Momjian |
---|---|
Тема | Re: solaris build problem with Sun compilers |
Дата | |
Msg-id | 200605172355.k4HNtZn20373@candle.pha.pa.us обсуждение исходный текст |
Ответ на | Re: solaris build problem with Sun compilers (Tom Lane <tgl@sss.pgh.pa.us>) |
Ответы |
Re: solaris build problem with Sun compilers
|
Список | pgsql-ports |
Tom Lane wrote: > Alan Stange <stange@rentec.com> writes: > > I believe the trick here is that Solaris 10 will only run on v9 hardware > > (or the sun4u systems), which all have the instruction. But the v8 ABI > > "model" doesn't have it. So, in some sense the ABI doesn't "allow" > > this instruction, but the hardware does, so they can just slam it in > > knowing that it'll work. > > Well, that might be OK for Sun's compiler since they know what a given > version of Solaris will run on. But I don't think we can adopt the same > attitude for our gcc code path; that has to work on Sparc-based Linuxen > and BSDen. I don't think it's appropriate to kiss off support for v8 > chips when we haven't seen any proof at all of a performance boost in > return. > > Maybe the right answer is to leave the code as-is, ie, deliberately not > the same for Sun and gcc compilers. OK, I have applied the following patch which documents that the Solaris CC TAS ASM only works for sparc9. Hopefully either sparc8 is not needed (unlikely) or someone will fix it. I have CC'ed the original contributor who added "cas". -- Bruce Momjian http://candle.pha.pa.us EnterpriseDB http://www.enterprisedb.com + If your life is a hard drive, Christ can be your backup. + Index: src/backend/port/tas/solaris_sparc.s =================================================================== RCS file: /cvsroot/pgsql/src/backend/port/tas/solaris_sparc.s,v retrieving revision 1.6 diff -c -c -r1.6 solaris_sparc.s *** src/backend/port/tas/solaris_sparc.s 17 May 2006 22:06:19 -0000 1.6 --- src/backend/port/tas/solaris_sparc.s 17 May 2006 23:42:40 -0000 *************** *** 16,21 **** --- 16,38 ---- .global pg_atomic_cas pg_atomic_cas: + ! "cas" only works on sparcv9 chips, and requies a compiler + ! that is targeting sparcv9. It will fail on a compiler + ! targeting sparcv8, and of course will not be understood + ! by a sparcv8 CPU. If this fails on existing Solaris + ! systems, we need to use a !defined(__sparcv9) test + ! to fall back to the old "ldstub" call for sparcv8 compiles. + ! gcc continues to use "ldstub" because there is no indication + ! which sparc version it is targeting. + ! + ! There actually is a trick for embedding "cas" for a compiler + ! that is targeting sparcv8: + ! + ! http://cvs.opensolaris.org/source/xref/on/usr/src/lib/libc/sparc/threads/sparc.il + ! + ! This might work for sparc8: + ! ldstub [%o0],%o1 ! moves only a byte + cas [%o0],%o2,%o1 mov %o1,%o0 retl Index: src/include/storage/s_lock.h =================================================================== RCS file: /cvsroot/pgsql/src/include/storage/s_lock.h,v retrieving revision 1.152 diff -c -c -r1.152 s_lock.h *** src/include/storage/s_lock.h 29 Apr 2006 11:55:19 -0000 1.152 --- src/include/storage/s_lock.h 17 May 2006 23:43:03 -0000 *************** *** 311,316 **** --- 311,320 ---- { register slock_t _res; + /* + * See comment in /pg/backend/port/tas/solaris_sparc.s for why this + * uses "ldstub", and that file uses "cas". + */ __asm__ __volatile__( " ldstub [%2], %0 \n" : "=r"(_res), "+m"(*lock)
В списке pgsql-ports по дате отправления: