[PORTS] TAS definitions on Solaris x86 with GCC

Michael Crozier <[email protected]>
Newsgroups gmane.comp.db.postgresql.ports
Message-ID <[email protected]>
Hello,

I'm again looking at tas/spinlock build problems while investigating unusually 
high CPU usage during load testing.  My issue was first mentioned here: 

http://archives.postgresql.org/pgsql-ports/2005-09/msg00001.php

Version details:
  Postgresql 7.4.8
  Solaris 10, AMD64
  GCC 3.4.3

To my untrained eye, it appears that configure chooses two versions of tas() 
for this combination (regardless of 32/64-bitness).  I'm trying to determine 
whether this is a correct interpretation and if so, which version of tas() of 
the correct version to be using with GCC on Solaris.


When building Postgresql on Solaris using GCC, the configure script appears to 
link tas.s to tas/solaris_i386.s.  This file compiles in 32bit mode, but not 
in 64bit (I manually linked to dummy.s when compiling in 64bit).  The 
following symbols are from the 32bit build.

   $ nm src/backend/port/tas.o 
   00000000 T tas
   $ nm src/backend/port/SUBSYS.o  | grep tas
   00000c90 T tas


In addition to tas.s, configure also enables the proper #defs for the inline 
tas() definition in s_lock.h:

   --- from line 97 ---
   #if defined(__i386__) || defined(__x86_64__) /* AMD Opteron */
   #define TAS(lock) tas(lock)
   
   static __inline__ int
   tas(volatile slock_t *lock)
   {
   	register slock_t _res = 1;
   
   	__asm__ __volatile__(
   		"	lock			\n"
   		"	xchgb	%0,%1	\n"
   :		"=q"(_res), "=m"(*lock)
   :		"0"(_res));
   	return (int) _res;
   }

These three tas symbols included from s_lock.h:

   src/backend/storage/lmgr/lwlock.o
   000002fa t tas
   src/backend/storage/lmgr/proc.o
   00000483 t tas
   src/backend/storage/lmgr/s_lock.o
   0000017b t tas

   src/backend/storage/lmgr/SUBSYS.o
   000047e2 t tas
   0000270b t tas
   00004c3b t tas


Thanks for any suggestions or insight,

 Michael Crozier



---------------------------(end of broadcast)---------------------------
TIP 3: Have you checked our extensive FAQ?

               http://www.postgresql.org/docs/faq
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.