Upgrade Boehm GC to 7.2alpha4.

[cacao.git] / src / mm / boehm-gc / doc / README.solaris2

diff --git a/src/mm/boehm-gc/doc/README.solaris2 b/src/mm/boehm-gc/doc/README.solaris2
index 31e7500382dd6984fea151583664902d20abcf52..f91410633c872572bce52d393d9dc78b2075b49f 100644 (file)
--- a/src/mm/boehm-gc/doc/README.solaris2
+++ b/src/mm/boehm-gc/doc/README.solaris2
@@ -20,8 +20,10 @@ You may want to reverse this decisions if you use -DREDIRECT_MALLOC=...
 
 SOLARIS THREADS:
 
-The collector must be compiled with -DGC_SOLARIS_THREADS (thr_ functions)
-or -DGC_SOLARIS_PTHREADS (pthread_ functions) to be thread safe.
+The collector must be compiled with -DGC_THREADS to be thread safe.
+This assumes use of the pthread_ interface.  Old style Solaris threads
+are no longer supported.
+
 It is also essential that gc.h be included in files that call thr_create,
 thr_join, thr_suspend, thr_continue, or dlopen.  Gc.h macro defines
 these to also do GC bookkeeping, etc.  Gc.h must be included with
@@ -30,20 +32,15 @@ these replacements are not visible.
 A collector built in this way way only be used by programs that are
 linked with the threads library.
 
-In this mode, the collector contains various workarounds for older Solaris
-bugs.  Mostly, these should not be noticeable unless you look at system
-call traces.  However, it cannot protect a guard page at the end of
-a thread stack.  If you know that you will only be running Solaris2.5
-or later, it should be possible to fix this by compiling the collector
-with -DSOLARIS23_MPROTECT_BUG_FIXED.
-
 Since 5.0 alpha5, dlopen disables collection temporarily,
 unless USE_PROC_FOR_LIBRARIES is defined.  In some unlikely cases, this
 can result in unpleasant heap growth.  But it seems better than the
 race/deadlock issues we had before.
 
 If solaris_threads are used on an X86 processor with malloc redirected to
-GC_malloc a deadlock is likely to result.
+GC_malloc, it is necessary to call GC_thr_init explicitly before forking the
+first thread.  (This avoids a deadlock arising from calling GC_thr_init
+with the allocation lock held.)
 
 It appears that there is a problem in using gc_cpp.h in conjunction with
 Solaris threads and Sun's C++ runtime.  Apparently the overloaded new operator
@@ -55,6 +52,13 @@ have it invoke the garbage-collector's allocators only after main has started.
 (Note that the latter requires a moderately expensive test in operator
 delete.)
 
+I encountered "symbol <unknown>: offet .... is non-aligned" errors.  These
+appear to be traceable to the use of the GNU assembler with the Sun linker.
+The former appears to generate a relocation not understood by the latter.
+The fix appears to be to use a consistent tool chain.  (As a non-Solaris-expert
+my solution involved hacking the libtool script, but I'm sure you can
+do something less ugly.)
+
 Hans-J. Boehm
 (The above contains my personal opinions, which are probably not shared
 by anyone else.)