obtained gcc-4.6.4.tar.bz2 from upstream website;upstream

verified gcc-4.6.4.tar.bz2.sig;
imported gcc-4.6.4 source tree from verified upstream tarball.

downloading a git-generated archive based on the 'upstream' tag
should provide you with a source tree that is binary identical
to the one extracted from the above tarball.

if you have obtained the source via the command 'git clone',
however, do note that line-endings of files in your working
directory might differ from line-endings of the respective
files in the upstream repository.

1 files changed, 60 insertions, 0 deletions

diff --git a/boehm-gc/doc/README.solaris2 b/boehm-gc/doc/README.solaris2
new file mode 100644
index 000000000..31e750038
--- /dev/null
+++ b/boehm-gc/doc/README.solaris2
@@ -0,0 +1,60 @@
+The collector supports both incremental collection and threads under
+Solaris 2.  The incremental collector normally retrieves page dirty information
+through the appropriate /proc calls.  But it can also be configured
+(by defining MPROTECT_VDB instead of PROC_VDB in gcconfig.h) to use mprotect
+and signals.  This may result in shorter pause times, but it is no longer
+safe to issue arbitrary system calls that write to the heap.
+
+Under other UNIX versions,
+the collector normally obtains memory through sbrk.  There is some reason
+to expect that this is not safe if the client program also calls the system
+malloc, or especially realloc.  The sbrk man page strongly suggests this is
+not safe: "Many library routines use malloc() internally, so use brk()
+and sbrk() only when you know  that malloc() definitely will not be used by
+any library routine."  This doesn't make a lot of sense to me, since there
+seems to be no documentation as to which routines can transitively call malloc.
+Nonetheless, under Solaris2, the collector now (since 4.12) allocates
+memory using mmap by default.  (It defines USE_MMAP in gcconfig.h.)
+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.
+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
+one or both of these macros defined, otherwise
+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.
+
+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
+is invoked by some iostream initialization code before threads are correctly
+initialized.  As a result, call to thr_self() in garbage collector
+initialization  segfaults.  Currently the only known workaround is to not
+invoke the garbage collector from a user defined global operator new, or to
+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.)
+
+Hans-J. Boehm
+(The above contains my personal opinions, which are probably not shared
+by anyone else.)