pgsql: Modify Solaris compiler build rules to use the cpp preprocessor,

Bruce Momjian wrote:

Log Message:
-----------
Modify Solaris compiler build rules to use the cpp preprocessor, the the
x86 file.

Well it compiles now, but it doesn't seem to work:

http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=kudu&dt=2006-04-28%2016:30:01

selecting default max_connections ... Abort - core dumped

creating template1 database in
/export/home/pgfarm/forte/HEAD/pgsql.5120/src/test/regress/./tmp_check/data/base/1
... PANIC: stuck spinlock (dd0000b0) detected at lwlock.c:358

Kris Jurka wrote:

Bruce Momjian wrote:

Log Message:
-----------
Modify Solaris compiler build rules to use the cpp preprocessor, the the
x86 file.

Well it compiles now, but it doesn't seem to work:

http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=kudu&dt=2006-04-28%2016:30:01

selecting default max_connections ... Abort - core dumped

creating template1 database in
/export/home/pgfarm/forte/HEAD/pgsql.5120/src/test/regress/./tmp_check/data/base/1
... PANIC: stuck spinlock (dd0000b0) detected at lwlock.c:358

OK, now that I have modified the build system to properly handle the
preprocessing, it seems we have a problem with the ASM instructions.

Theo? Comments?

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Bruce Momjian wrote:

Kris Jurka wrote:

Bruce Momjian wrote:

Log Message:
-----------
Modify Solaris compiler build rules to use the cpp preprocessor, the the
x86 file.

Well it compiles now, but it doesn't seem to work:

http://pgbuildfarm.org/cgi-bin/show_log.pl?nm=kudu&dt=2006-04-28%2016:30:01

selecting default max_connections ... Abort - core dumped

creating template1 database in
/export/home/pgfarm/forte/HEAD/pgsql.5120/src/test/regress/./tmp_check/data/base/1
... PANIC: stuck spinlock (dd0000b0) detected at lwlock.c:358

OK, now that I have modified the build system to properly handle the
preprocessing, it seems we have a problem with the ASM instructions.

Theo? Comments?

What platform is that? (OS rev, architecture and word size)? I tested
the changes I submitted on Solaris 10 amd64.

--
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// Ecelerity: Run with it. -- http://www.omniti.com/

On Fri, 28 Apr 2006, Theo Schlossnagle wrote:

What platform is that? (OS rev, architecture and word size)? I tested the
changes I submitted on Solaris 10 amd64.

$ uname -a
SunOS albert 5.9 Generic_112234-03 i86pc i386 i86pc
$ cc -V
cc: Sun WorkShop 6 update 2 C 5.3 Patch 111680-09 2003/05/18

Kris Jurka

Kris Jurka wrote:

On Fri, 28 Apr 2006, Theo Schlossnagle wrote:

What platform is that? (OS rev, architecture and word size)? I
tested the changes I submitted on Solaris 10 amd64.

$ uname -a
SunOS albert 5.9 Generic_112234-03 i86pc i386 i86pc
$ cc -V
cc: Sun WorkShop 6 update 2 C 5.3 Patch 111680-09 2003/05/18

Kris Jurka

The file that uses the spinlocks:
/src/backend/storage/lmgr/s_lock.c

can be compiled standalone with -DS_LOCK_TEST

Can you compile that and run the test. I'd be happy to troubleshoot it
hands-on, but I don't have access to that box.

Best regards,
Theo

--
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// Ecelerity: Run with it. -- http://www.omniti.com/

On Fri, 28 Apr 2006, Theo Schlossnagle wrote:

The file that uses the spinlocks:
/src/backend/storage/lmgr/s_lock.c

can be compiled standalone with -DS_LOCK_TEST

To get the test to compile I had to link in tas.o as the attached patch
shows. Unfortunately this doesn't work for platforms that don't have a
tas.o, bailing out with file not found. Perhaps it's not important to fix
this test, but I thought I'd mention it.

Anyway the test exits with

Stuck spinlock (80618e9) detected at ./s_lock.c:355.

on a linux gcc build this exits with

Stuck spinlock (0x5013ad) detected at ./s_lock.c:402.

Kris Jurka

Kris Jurka wrote:

On Fri, 28 Apr 2006, Theo Schlossnagle wrote:

The file that uses the spinlocks:
/src/backend/storage/lmgr/s_lock.c

can be compiled standalone with -DS_LOCK_TEST

To get the test to compile I had to link in tas.o as the attached
patch shows. Unfortunately this doesn't work for platforms that don't
have a tas.o, bailing out with file not found. Perhaps it's not
important to fix this test, but I thought I'd mention it.

Anyway the test exits with

Stuck spinlock (80618e9) detected at ./s_lock.c:355.

on a linux gcc build this exits with

Stuck spinlock (0x5013ad) detected at ./s_lock.c:402.

This seems like a different problem, no? The patch I sent in didn't
touch any of the linux assembly bits. The linux test should pass to the
end without an issue right?

--
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// Ecelerity: Run with it. -- http://www.omniti.com/

On Fri, 28 Apr 2006, Theo Schlossnagle wrote:

Kris Jurka wrote:

Anyway the test exits with
Stuck spinlock (80618e9) detected at ./s_lock.c:355.

on a linux gcc build this exits with
Stuck spinlock (0x5013ad) detected at ./s_lock.c:402.

This seems like a different problem, no? The patch I sent in didn't touch
any of the linux assembly bits. The linux test should pass to the end
without an issue right?

No, that's the desired ending. It prints:

S_LOCK_TEST: this will print 1000 stars and then
exit with a 'stuck spinlock' message
if S_LOCK() and TAS() are working.

The solaris version is just getting stuck before at another point before
the expected stuck point.

Kris Jurka

Kris Jurka wrote:

On Fri, 28 Apr 2006, Theo Schlossnagle wrote:

Kris Jurka wrote:

Anyway the test exits with
Stuck spinlock (80618e9) detected at ./s_lock.c:355.

on a linux gcc build this exits with
Stuck spinlock (0x5013ad) detected at ./s_lock.c:402.

This seems like a different problem, no? The patch I sent in didn't
touch any of the linux assembly bits. The linux test should pass to
the end without an issue right?

No, that's the desired ending. It prints:

S_LOCK_TEST: this will print 1000 stars and then
exit with a 'stuck spinlock' message
if S_LOCK() and TAS() are working.

The solaris version is just getting stuck before at another point before
the expected stuck point.

My workstation is running 32bit solaris.. I can build and debug it
here... I'll give that a spin (hehe).

--
// Theo Schlossnagle
// Principal Engineer -- http://www.omniti.com/~jesus/
// Ecelerity: Run with it. -- http://www.omniti.com/

Kris Jurka wrote:

On Fri, 28 Apr 2006, Theo Schlossnagle wrote:

The file that uses the spinlocks:
/src/backend/storage/lmgr/s_lock.c

can be compiled standalone with -DS_LOCK_TEST

To get the test to compile I had to link in tas.o as the attached patch
shows. Unfortunately this doesn't work for platforms that don't have a
tas.o, bailing out with file not found. Perhaps it's not important to fix
this test, but I thought I'd mention it.

Fixed with the attached patch. Thanks.

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +

Theo Schlossnagle wrote:

Kris Jurka wrote:

On Fri, 28 Apr 2006, Theo Schlossnagle wrote:

Kris Jurka wrote:

Anyway the test exits with
Stuck spinlock (80618e9) detected at ./s_lock.c:355.

on a linux gcc build this exits with
Stuck spinlock (0x5013ad) detected at ./s_lock.c:402.

This seems like a different problem, no? The patch I sent in didn't
touch any of the linux assembly bits. The linux test should pass to
the end without an issue right?

No, that's the desired ending. It prints:

S_LOCK_TEST: this will print 1000 stars and then
exit with a 'stuck spinlock' message
if S_LOCK() and TAS() are working.

The solaris version is just getting stuck before at another point before
the expected stuck point.

I downloaded and tested this on my box. The first thing I noticed is
that when compiling tas.s on Solaris 10 the -P flag was omitted (which
is needed to have the #ifdef's process correctly). I did an: as -P
tas.s by hand and then was able to repeat your problem.

You should see in backend/port/Makfile:

$(CC) $(CFLAGS) -c -P $<

Perhaps you didn't get that version yet.

Looks like part of my patch wasn't applied (or I neglected to send it
all). The cas operations are all word operations so the slock_t _MUST_
be changed to a word.

Sorry, yes, that is my fault. I had to modify the macro test you
defined from __amd64 to __x86_64__, and didn't see the change in the
typedef. Fix applied.

---------------------------------------------------------------------------

In src/include/storage/s_lock.h in the sun section, the slock_t must be
an unsigned int:

; cvs diff -u src/include/storage/s_lock.h
Index: src/include/storage/s_lock.h
===================================================================
RCS file: /projects/cvsroot/pgsql/src/include/storage/s_lock.h,v
retrieving revision 1.151
diff -u -r1.151 s_lock.h
--- src/include/storage/s_lock.h        28 Apr 2006 03:43:19 -0000      
1.151
+++ src/include/storage/s_lock.h        29 Apr 2006 02:48:45 -0000
@@ -765,7 +765,7 @@

#if defined(__sun) && (defined(__i386) || defined(__x86_64__) ||
defined(__sparc__) || defined(__sparc))
#define HAS_TEST_AND_SET
-typedef unsigned char slock_t;
+typedef unsigned int slock_t;

extern slock_t pg_atomic_cas(volatile slock_t *lock, slock_t with,

slock_t cmp);

--
Bruce Momjian http://candle.pha.pa.us
EnterpriseDB http://www.enterprisedb.com

+ If your life is a hard drive, Christ can be your backup. +