Thread: Fatal compiler/assembler errors (PostgreSQL 7.0.2/NetBSD 1.4.2/VAX)
Is this a problem with PostgreSQL or a buggy assembler?
In file included from xlog.c:28:
../../../include/storage/s_lock.h:158: redefinition of `slock_t'
../../../include/os.h:43: `slock_t' previously declared here
../../../include/storage/s_lock.h: In function `tas':
../../../include/storage/s_lock.h:163: warning: type defaults to `int' in declaration of `_res'
{standard input}: Assembler messages:
{standard input}:119: Warning: Ignoring statement due to "Too many operands"
{standard input}:119: Warning: Junk at end of expression "bbssi $0"
{standard input}:128: Warning: Ignoring statement due to "Too many operands"
{standard input}:128: Warning: Junk at end of expression "bbssi $0"
{standard input}:152: Warning: Ignoring statement due to "Too many operands"
{standard input}:152: Warning: Junk at end of expression "bbssi $0"
{standard input}:159: Warning: Ignoring statement due to "Too many operands"
{standard input}:159: Warning: Junk at end of expression "bbssi $0"
{standard input}:187: Warning: Ignoring statement due to "Too many operands"
{standard input}:187: Warning: Junk at end of expression "bbssi $0"
{standard input}:520: Warning: Ignoring statement due to "Too many operands"
{standard input}:520: Warning: Junk at end of expression "bbssi $0"
{standard input}:576: Warning: Ignoring statement due to "Too many operands"
{standard input}:576: Warning: Junk at end of expression "bbssi $0"
{standard input}:614: Warning: Ignoring statement due to "Too many operands"
{standard input}:614: Warning: Junk at end of expression "bbssi $0"
{standard input}:665: Warning: Ignoring statement due to "Too many operands"
{standard input}:665: Warning: Junk at end of expression "bbssi $0"
{standard input}:770: Warning: Ignoring statement due to "Too many operands"
{standard input}:770: Warning: Junk at end of expression "bbssi $0"
{standard input}:815: Warning: Ignoring statement due to "Too many operands"
{standard input}:815: Warning: Junk at end of expression "bbssi $0"
{standard input}:853: Warning: Ignoring statement due to "Too many operands"
{standard input}:853: Warning: Junk at end of expression "bbssi $0"
{standard input}:987: Warning: Ignoring statement due to "Too many operands"
{standard input}:987: Warning: Junk at end of expression "bbssi $0"
{standard input}:1197: Warning: Ignoring statement due to "Too many operands"
{standard input}:1197: Warning: Junk at end of expression "bbssi $0"
xlog.c: At top level:
xlog.c:817: warning: `ReadRecord' defined but not used
make[3]: *** [xlog.o] Error 1
make[3]: Leaving directory `/usr/src/postgresql-7.0.2/src/backend/access/transam'
make[2]: *** [submake] Error 2
make[2]: Leaving directory `/usr/src/postgresql-7.0.2/src/backend/access'
make[1]: *** [access.dir] Error 2
make[1]: Leaving directory `/usr/src/postgresql-7.0.2/src/backend'
make: *** [all] Error 2
--
"For competitive reasons we can't tell you the location of our fiber."
-- An anonymous representative of a very large telco
"For competitive reasons we can't tell you the location of our backhoe."
-- An anonymous representative of a contractor.
Jeff Workman writes:
> Is this a problem with PostgreSQL or a buggy assembler?
PostgreSQL -- Apparently no one tried to use a VAX in a while.
> In file included from xlog.c:28:
> ../../../include/storage/s_lock.h:158: redefinition of `slock_t'
> ../../../include/os.h:43: `slock_t' previously declared here
Remove the one in s_lock.h.
> ../../../include/storage/s_lock.h: In function `tas':
> ../../../include/storage/s_lock.h:163: warning: type defaults to `int' in declaration of `_res'
Add int there if you like.
> {standard input}: Assembler messages:
> {standard input}:119: Warning: Ignoring statement due to "Too many operands"
> {standard input}:119: Warning: Junk at end of expression "bbssi $0"
This one got messed up during a code indentation run. The code around
line 165 in s_lock.h should look like the one below (reconstructed from
latest good revision). I don't have a clue how the assembly code actually
works, there might be requirements regarding whitespace that do not show
very well. If you have problems, you might find help on this issue in a
netbsd/vax forum.
Let us know how it turns out.
static __inline__ int
tas(volatile slock_t *lock)
{
register _res;
__asm__(" movl $1, r0
bbssi $0, (%1), 1f
clrl r0
1: movl r0, %0 "
: "=r"(_res) /* return value, in register */
: "r"(lock) /* argument, 'lock pointer', in register */
: "r0"); /* inline code uses this register */
return (int) _res;
}
--
Peter Eisentraut peter_e@gmx.net http://yi.org/peter-e/
Stoned koala bears drooled eucalyptus spit in awe as Peter Eisentraut exclaimed:
> Jeff Workman writes:
>
> > Is this a problem with PostgreSQL or a buggy assembler?
>
> PostgreSQL -- Apparently no one tried to use a VAX in a while.
It's actually rather comforting to know that there's not anybody else out
there in the world sick enough to try this on a VAX. I'll sleep better at
night knowing this. :).
> Let us know how it turns out.
Well, it's still compiling but it made it past this part ok this
time. I'll follow-up in a couple of weeks (it'll probably take that long
to build) and let everybody know if it actually turned out ok.
Jeff
--
"For competitive reasons we can't tell you the location of our fiber."
-- An anonymous representative of a very large telco
"For competitive reasons we can't tell you the location of our backhoe."
-- An anonymous representative of a contractor.
There was a message about six months ago about someone trying to get to work on a VAX. Check the archvie on www.postgresql.org. > Stoned koala bears drooled eucalyptus spit in awe as Peter Eisentraut exclaimed: > > > Jeff Workman writes: > > > > > Is this a problem with PostgreSQL or a buggy assembler? > > > > PostgreSQL -- Apparently no one tried to use a VAX in a while. > > It's actually rather comforting to know that there's not anybody else out > there in the world sick enough to try this on a VAX. I'll sleep better at > night knowing this. :). > > > Let us know how it turns out. > > Well, it's still compiling but it made it past this part ok this > time. I'll follow-up in a couple of weeks (it'll probably take that long > to build) and let everybody know if it actually turned out ok. > > Jeff > > -- > "For competitive reasons we can't tell you the location of our fiber." > -- An anonymous representative of a very large telco > "For competitive reasons we can't tell you the location of our backhoe." > -- An anonymous representative of a contractor. > > -- Bruce Momjian | http://candle.pha.pa.us pgman@candle.pha.pa.us | (610) 853-3000 + If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania 19026