aboutsummaryrefslogtreecommitdiff
path: root/boehm-gc/doc/README.linux
diff options
context:
space:
mode:
Diffstat (limited to 'boehm-gc/doc/README.linux')
-rw-r--r--boehm-gc/doc/README.linux41
1 files changed, 19 insertions, 22 deletions
diff --git a/boehm-gc/doc/README.linux b/boehm-gc/doc/README.linux
index 1d0fd4c3fb6..dc0fa543dc2 100644
--- a/boehm-gc/doc/README.linux
+++ b/boehm-gc/doc/README.linux
@@ -11,7 +11,7 @@ Incremental GC is generally supported.
Dynamic libraries are supported on an ELF system. A static executable
should be linked with the gcc option "-Wl,-defsym,_DYNAMIC=0".
-The collector appears to work reliably with Linux threads, but beware
+The collector appears to work reliably with Linux threads, but beware
of older versions of glibc and gdb.
The garbage collector uses SIGPWR and SIGXCPU if it is used with
@@ -19,17 +19,17 @@ Linux threads. These should not be touched by the client program.
To use threads, you need to abide by the following requirements:
-1) You need to use LinuxThreads (which are included in libc6).
+1) You need to use LinuxThreads or NPTL (which are included in libc6).
The collector relies on some implementation details of the LinuxThreads
- package. It is unlikely that this code will work on other
+ package. This code may not work on other
pthread implementations (in particular it will *not* work with
MIT pthreads).
-2) You must compile the collector with -DGC_LINUX_THREADS and -D_REENTRANT
- specified in the Makefile.
+2) You must compile the collector with -DGC_LINUX_THREADS (or
+ just -DGC_THREADS) and -D_REENTRANT specified in the Makefile.
-3a) Every file that makes thread calls should define GC_LINUX_THREADS and
+3a) Every file that makes thread calls should define GC_LINUX_THREADS and
_REENTRANT and then include gc.h. Gc.h redefines some of the
pthread primitives as macros which also provide the collector with
information it requires.
@@ -37,14 +37,14 @@ To use threads, you need to abide by the following requirements:
3b) A new alternative to (3a) is to build the collector and compile GC clients
with -DGC_USE_LD_WRAP, and to link the final program with
- (for ld) --wrap read --wrap dlopen --wrap pthread_create \
- --wrap pthread_join --wrap pthread_detach \
- --wrap pthread_sigmask --wrap sleep
+ (for ld) --wrap dlopen --wrap pthread_create \
+ --wrap pthread_join --wrap pthread_detach \
+ --wrap pthread_sigmask --wrap pthread_exit --wrap pthread_cancel
- (for gcc) -Wl,--wrap -Wl,read -Wl,--wrap -Wl,dlopen -Wl,--wrap \
- -Wl,pthread_create -Wl,--wrap -Wl,pthread_join -Wl,--wrap \
- -Wl,pthread_detach -Wl,--wrap -Wl,pthread_sigmask \
- -Wl,--wrap -Wl,sleep
+ (for gcc) -Wl,--wrap -Wl,dlopen -Wl,--wrap -Wl,pthread_create \
+ -Wl,--wrap -Wl,pthread_join -Wl,--wrap -Wl,pthread_detach \
+ -Wl,--wrap -Wl,pthread_sigmask -Wl,--wrap -Wl,pthread_exit \
+ -Wl,--wrap -Wl,pthread_cancel
In any case, _REENTRANT should be defined during compilation.
@@ -55,17 +55,16 @@ To use threads, you need to abide by the following requirements:
conditions, this may cause unexpected heap growth.
5) The combination of GC_LINUX_THREADS, REDIRECT_MALLOC, and incremental
- collection fails in seemingly random places. This hasn't been tracked
- down yet, but is perhaps not completely astonishing. The thread package
- uses malloc, and thus can presumably get SIGSEGVs while inside the
- package. There is no real guarantee that signals are handled properly
- at that point.
+ collection is probably not fully reliable, though it now seems to work
+ in simple cases.
6) Thread local storage may not be viewed as part of the root set by the
collector. This probably depends on the linuxthreads version. For the
time being, any collectable memory referenced by thread local storage should
also be referenced from elsewhere, or be allocated as uncollectable.
- (This is really a bug that should be fixed somehow.)
+ (This is really a bug that should be fixed somehow. The current GC
+ version probably gets things right if there are not too many tls locations
+ and if dlopen is not used.)
M68K LINUX:
@@ -76,7 +75,7 @@ patches to correct the problem in 68040 buserror handler but it is not
yet in any standard kernel.
Here is a simple test program to detect whether the kernel has the
-problem. It could be run as a separate check in configure or tested
+problem. It could be run as a separate check in configure or tested
upon startup. If it fails (return !0) than mprotect can't be used
on that system.
@@ -128,5 +127,3 @@ main()
fprintf(stderr,"vmtest Ok\n");
exit(0);
}
-
-