[ cc'ing Remi to see if he remembers anything about how he got around this ]
Stefan Kaltenbrunner <stefan@kaltenbrunner.cc> writes:
> FWIW: there also seems to be a fairly indepth discussion on the cobalt
> related netbsd list from last year about a problem that looks very
> similiar (at least to you issue with etch):
> http://www.nabble.com/Strange-segmentation-fault-trying-to-run-postgresql-on-current-to9997129.html
Hmm. I'm not sure it's the same problem, because what they were getting
was SIGSEGV not SIGBUS. OTOH I would think the latter is a more correct
errno for reporting an alignment trap, so maybe the NetBSD kernel has
been fixed since then to report SIGBUS for this case.
Anyway, it would be easy to verify this theory by looking at the
instruction stream and registers in Glyn's dump, to see if it's trying
to store at a non-aligned address.
The conclusion of the thread seemed to be that it was a linker or
assembler problem triggered by our use of SUBSYS.o files to aggregate
all the backend .o files into a smaller number of files for the final
link. If so the answer is either (a) update to a newer toolchain
that might fix the problem, or (b) try our CVS HEAD which doesn't
use the SUBSYS.o trick anymore. Mind you, I'd not especially recommend
trying to run CVS HEAD for production purposes, but it would be real
interesting at this point to see if you can compile it and run the
regression tests with the toolchain you've got.
regards, tom lane
