1 See README.alpha for Linux on DEC AXP info.
3 This file applies mostly to Linux/Intel IA32. Ports to Linux on an M68K
4 and PowerPC are also integrated. They should behave similarly, except that
5 the PowerPC port lacks incremental GC support, and it is unknown to what
6 extent the Linux threads code is functional.
8 Incremental GC is supported on Intel IA32 and M68K.
10 Dynamic libraries are supported on an ELF system. A static executable
11 should be linked with the gcc option "-Wl,-defsym,_DYNAMIC=0".
13 The collector appears to work with Linux threads. We have seen
14 intermittent hangs in sem_wait. So far we have been unable to reproduce
15 these unless the process was being debugged or traced. Thus it's
16 possible that the only real issue is that the debugger loses
17 signals on rare occasions.
19 The garbage collector uses SIGPWR and SIGXCPU if it is used with
20 Linux threads. These should not be touched by the client program.
22 To use threads, you need to abide by the following requirements:
24 1) You need to use LinuxThreads (which are included in libc6).
26 The collector relies on some implementation details of the LinuxThreads
27 package. It is unlikely that this code will work on other
28 pthread implementations (in particular it will *not* work with
31 2) You must compile the collector with -DLINUX_THREADS and -D_REENTRANT
32 specified in the Makefile.
34 3) Every file that makes thread calls should define LINUX_THREADS and
35 _REENTRANT and then include gc.h. Gc.h redefines some of the
36 pthread primitives as macros which also provide the collector with
37 information it requires.
39 4) Currently dlopen() is probably not safe. The collector must traverse
40 the list of libraries maintained by the runtime loader. That can
41 probably be an inconsistent state when a thread calling the loader is
42 is stopped for GC. (It's possible that this is fixable in the
43 same way it is handled for SOLARIS_THREADS, with GC_dlopen.)
45 5) The combination of LINUX_THREADS, REDIRECT_MALLOC, and incremental
46 collection fails in seemingly random places. This hasn't been tracked
47 down yet, but is perhaps not completely astonishing. The thread package
48 uses malloc, and thus can presumably get SIGSEGVs while inside the
49 package. There is no real guarantee that signals are handled properly