Thread: odd 7.4 build failure on new sparc machine
I am seeing a strange failure on the new box Sun donated, when trying to build 7.4 for the buildfarm. This is what I get: gmake[3]: Entering directory `/export/home/oicu/bf/root/REL7_4_STABLE/pgsql.5463/src/backend/port' ccache gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -I/export/home/oicu/mysw/include -c -o dynloader.o dynloader.c ccache gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -I/export/home/oicu/mysw/include -c -o pg_sema.o pg_sema.c ccache gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include -I/export/home/oicu/mysw/include -c -o pg_shmem.o pg_shmem.c pg_shmem.c: In function `PGSharedMemoryAttach': pg_shmem.c:394: warning: passing arg 1 of `shmdt' from incompatible pointer type ccache gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -c tas.s /usr/ccs/bin/ld -r -o SUBSYS.o dynloader.o pg_sema.o pg_shmem.o tas.o ld: fatal: relocation error: R_SPARC_32: file tas.o: symbol <unknown>: offset 0xec1 is non-aligned ld: fatal: relocation error: R_SPARC_32: file tas.o: symbol <unknown>: offset 0xec5 is non-aligned ld: fatal: relocation error: R_SPARC_32: file tas.o: symbol <unknown>: offset 0x115d is non-aligned ld: fatal: relocation error: R_SPARC_32: file tas.o: symbol <unknown>: offset 0x46 is non-aligned ld: fatal: relocation error: R_SPARC_32: file tas.o: symbol <unknown>: offset 0xeb7 is non-aligned ld: fatal: relocation error: R_SPARC_32: file tas.o: symbol <unknown>: offset 0xebd is non-aligned gmake[3]: *** [SUBSYS.o] Error 1 What is odd is that the identical file seems to succeeed on the later 8.0 and 8.1 branches. I also don't understand the logic of what's in the file: ldstub [%o0],%o0 !! !! if it was already set when we set it, somebody else already !! owned the lock -- return 1. !! cmp %o0,0 bne .LL2 mov 1,%o0 !! !! otherwise, it was clear and we now own the lock -- return 0. !! mov0,%o0 .LL2: !! !! this is a leaf procedure - no need to restore windows and !! diddle the CWP. !! retl Why do we have "mov 1,%o0" immediately followed by "mov 0,%o0"? As far as I can understand this code it doesn't seem to do what the comments say it does. I'm not sure I care that much about 7.4 on this new machine, but it did seem to me like it might indicate a deeper problem. cheers andrew
Andrew Dunstan wrote: > > I am seeing a strange failure on the new box Sun donated, when trying > to build 7.4 for the buildfarm. This is what I get: > > [snip] > > > What is odd is that the identical file seems to succeeed on the later > 8.0 and 8.1 branches. > > This part at least is not true - in the later branches we use dummy.s. So at this stage I think I will probably just abandon building 7.4 for this machine. cheers andrew
Andrew Dunstan <andrew@dunslane.net> writes:
> I am seeing a strange failure on the new box Sun donated, when trying to
> ccache gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes -Wmissing-declarations -c tas.s
> /usr/ccs/bin/ld -r -o SUBSYS.o dynloader.o pg_sema.o pg_shmem.o tas.o
> ld: fatal: relocation error: R_SPARC_32: file tas.o: symbol <unknown>: offset 0xec1 is non-aligned
> [etc]
> What is odd is that the identical file seems to succeeed on the later
> 8.0 and 8.1 branches.
The solaris_sparc.s file seems identical in these branches up to CVS
label ... but are the compilation options the same? The critical fix
might be somewhere in the configure/Makefile chain.
Another thing to try is whether it works without ccache. We've seen
plenty of trouble from that tool :-(
> Why do we have "mov 1,%o0" immediately followed by "mov 0,%o0"?
Better read up on branch delay slots...
regards, tom lane
Tom Lane said: > Andrew Dunstan <andrew@dunslane.net> writes: >> I am seeing a strange failure on the new box Sun donated, when trying >> to > >> ccache gcc -O2 -fno-strict-aliasing -g -Wall -Wmissing-prototypes >> -Wmissing-declarations -c tas.s /usr/ccs/bin/ld -r -o SUBSYS.o >> dynloader.o pg_sema.o pg_shmem.o tas.o ld: fatal: relocation error: >> R_SPARC_32: file tas.o: symbol <unknown>: offset 0xec1 is non-aligned >> [etc] > >> What is odd is that the identical file seems to succeeed on the later >> 8.0 and 8.1 branches. > > The solaris_sparc.s file seems identical in these branches up to CVS > label ... but are the compilation options the same? The critical fix > might be somewhere in the configure/Makefile chain. Yes - see later email where I concluded that. > > Another thing to try is whether it works without ccache. We've seen > plenty of trouble from that tool :-( I am still waiting to see a smoking gun on it. So far there has been some smoke but no gun or fire (sorry for mixed metaphor). What I am thinking of doing is having buildfarm blow away the cache on failure, so that ccache would be forced to recompile fropm scratch unless the last case was a success. Thoughts? >> Why do we have "mov 1,%o0" immediately followed by "mov 0,%o0"? > > Better read up on branch delay slots... > Yes, ok, I understand. I must have forgotten that one had to write the assembler in that non-linear fashion to get the benefit of saving an instruction cycle. cheers andrew