Would be nice to make it use the system copy instead.
Gauche expects that Boehm GC is compiled with DONT_ADD_BYTE_AT_END. But it is not enabled in dev-libs/boehm-gc. Also upstream author has recommended to use bundled boehm-gc.
Is there a reason why we should not make the system gc be compiled with DONT_ADD_BYTE_AT_END?
I don't know about Boehm GC, so I cannot answer your question.
Created attachment 204132 [details, diff] patch for boehm-gc to build with DONT_ADD_BYTE_AT_END
Created attachment 204133 [details, diff] patch to make gauche build against system boehm-gc
Created attachment 204134 [details, diff] patch for gauche ebuild to depend on boehm-gc [threads]
These three patches make gauche build against system boehm-gc, but this one should be patched and rebuild with the new changes. I've tested this, but it would be great if anyone can give any feedback in case I forgot something.
I found this in the docs: "Per object overhead. This is usually a relatively minor effect, but it may be worth considering. If the collector recognizes interior pointers, object sizes are increased, so that one-past-the-end pointers are correctly recognized. The collector can be configured not to do this (-DDONT_ADD_BYTE_AT_END). The collector rounds up object sizes so the result fits well into the chunk size (HBLKSIZE, normally 4K on 32 bit machines, 8K on 64 bit machines) used by the collector. Thus it may be worth avoiding objects of size 2K + 1 (or 2K if a byte is being added at the end.)"
matsuu, do you have an opinion about enabling -DDONT_ADD_BYTE_AT_END globally?
Tomas: I tried your patches to use the system gc for gauche. Gauche seems to build fine with it, though a few tests segfault (this is without DONT_ADD_BYTE_AT_END). I also tried the DONT_ADD_BYTE_AT_END patch for boehm-gc and it hangs somewhere in the tests: /bin/sh ./libtool --tag=CXX --mode=link x86_64-pc-linux-gnu-g++ -fexceptions -I libatomic_ops/src -march=core2 -O2 -pipe -ggdb -DDONT_ADD_BYTE_AT_END -Wl,-O1 -o test_cpp tests/test_cpp.o libgccpp.la ./libgc.la x86_64-pc-linux-gnu-g++ -fexceptions -I libatomic_ops/src -march=core2 -O2 -pipe -ggdb -DDONT_ADD_BYTE_AT_END -Wl,-O1 -o .libs/test_cpp tests/test_cpp.o ./.libs/libgccpp.so /var/tmp/portage/dev-libs/boehm-gc-7.1-r1/work/gc-7.1/.libs/libgc.so ./.libs/libgc.so -lpthread -ldl creating test_cpp make[2]: Leaving directory `/var/tmp/portage/dev-libs/boehm-gc-7.1-r1/work/gc-7.1' make check-TESTS make[2]: Entering directory `/var/tmp/portage/dev-libs/boehm-gc-7.1-r1/work/gc-7.1' Switched to incremental mode Emulating dirty bits with mprotect/signals It hangs there for minutes. The unpatched boehm-gc ebuild has no such hangs.
(In reply to comment #10) > Tomas: I tried your patches to use the system gc for gauche. Gauche seems to > build fine with it, though a few tests segfault (this is without > DONT_ADD_BYTE_AT_END). I also tried the DONT_ADD_BYTE_AT_END patch for boehm-gc > and it hangs somewhere in the tests: > > /bin/sh ./libtool --tag=CXX --mode=link x86_64-pc-linux-gnu-g++ -fexceptions -I > libatomic_ops/src -march=core2 -O2 -pipe -ggdb -DDONT_ADD_BYTE_AT_END -Wl,-O1 > -o test_cpp tests/test_cpp.o libgccpp.la ./libgc.la > x86_64-pc-linux-gnu-g++ -fexceptions -I libatomic_ops/src -march=core2 -O2 > -pipe -ggdb -DDONT_ADD_BYTE_AT_END -Wl,-O1 -o .libs/test_cpp tests/test_cpp.o > ./.libs/libgccpp.so > /var/tmp/portage/dev-libs/boehm-gc-7.1-r1/work/gc-7.1/.libs/libgc.so > ./.libs/libgc.so -lpthread -ldl > creating test_cpp > make[2]: Leaving directory > `/var/tmp/portage/dev-libs/boehm-gc-7.1-r1/work/gc-7.1' > make check-TESTS > make[2]: Entering directory > `/var/tmp/portage/dev-libs/boehm-gc-7.1-r1/work/gc-7.1' > Switched to incremental mode > Emulating dirty bits with mprotect/signals > > It hangs there for minutes. The unpatched boehm-gc ebuild has no such hangs. > I see what you mean... I didn't force the tests before... Boehm-gc is emerged without any problems, and with that done, gauche's test wont give any segfaults... I think it's a gcc problem, I've switched from 4.3.4 to 4.4.1, and now it doesn't hang anymore. I did this: USE="threads" ebuild boehm-gc-7.1.ebuild clean unpack compile test
Created attachment 204532 [details] Here's the log of the testing part with gcc-4.4.1
It seems that using the bundled version of Boehm GC is best solution.
