Mercurial > emacs
comparison gc/doc/README.linux @ 51488:5de98dce4bd1
*** empty log message ***
author | Dave Love <fx@gnu.org> |
---|---|
date | Thu, 05 Jun 2003 17:49:22 +0000 |
parents | |
children |
comparison
equal
deleted
inserted
replaced
51487:01d68b199093 | 51488:5de98dce4bd1 |
---|---|
1 See README.alpha for Linux on DEC AXP info. | |
2 | |
3 This file applies mostly to Linux/Intel IA32. Ports to Linux on an M68K, IA64, | |
4 SPARC, MIPS, Alpha and PowerPC are also integrated. They should behave | |
5 similarly, except that the PowerPC port lacks incremental GC support, and | |
6 it is unknown to what extent the Linux threads code is functional. | |
7 See below for M68K specific notes. | |
8 | |
9 Incremental GC is generally supported. | |
10 | |
11 Dynamic libraries are supported on an ELF system. A static executable | |
12 should be linked with the gcc option "-Wl,-defsym,_DYNAMIC=0". | |
13 | |
14 The collector appears to work reliably with Linux threads, but beware | |
15 of older versions of glibc and gdb. | |
16 | |
17 The garbage collector uses SIGPWR and SIGXCPU if it is used with | |
18 Linux threads. These should not be touched by the client program. | |
19 | |
20 To use threads, you need to abide by the following requirements: | |
21 | |
22 1) You need to use LinuxThreads (which are included in libc6). | |
23 | |
24 The collector relies on some implementation details of the LinuxThreads | |
25 package. It is unlikely that this code will work on other | |
26 pthread implementations (in particular it will *not* work with | |
27 MIT pthreads). | |
28 | |
29 2) You must compile the collector with -DGC_LINUX_THREADS and -D_REENTRANT | |
30 specified in the Makefile. | |
31 | |
32 3a) Every file that makes thread calls should define GC_LINUX_THREADS and | |
33 _REENTRANT and then include gc.h. Gc.h redefines some of the | |
34 pthread primitives as macros which also provide the collector with | |
35 information it requires. | |
36 | |
37 3b) A new alternative to (3a) is to build the collector and compile GC clients | |
38 with -DGC_USE_LD_WRAP, and to link the final program with | |
39 | |
40 (for ld) --wrap read --wrap dlopen --wrap pthread_create \ | |
41 --wrap pthread_join --wrap pthread_detach \ | |
42 --wrap pthread_sigmask --wrap sleep | |
43 | |
44 (for gcc) -Wl,--wrap -Wl,read -Wl,--wrap -Wl,dlopen -Wl,--wrap \ | |
45 -Wl,pthread_create -Wl,--wrap -Wl,pthread_join -Wl,--wrap \ | |
46 -Wl,pthread_detach -Wl,--wrap -Wl,pthread_sigmask \ | |
47 -Wl,--wrap -Wl,sleep | |
48 | |
49 In any case, _REENTRANT should be defined during compilation. | |
50 | |
51 4) Dlopen() disables collection during its execution. (It can't run | |
52 concurrently with the collector, since the collector looks at its | |
53 data structures. It can't acquire the allocator lock, since arbitrary | |
54 user startup code may run as part of dlopen().) Under unusual | |
55 conditions, this may cause unexpected heap growth. | |
56 | |
57 5) The combination of GC_LINUX_THREADS, REDIRECT_MALLOC, and incremental | |
58 collection fails in seemingly random places. This hasn't been tracked | |
59 down yet, but is perhaps not completely astonishing. The thread package | |
60 uses malloc, and thus can presumably get SIGSEGVs while inside the | |
61 package. There is no real guarantee that signals are handled properly | |
62 at that point. | |
63 | |
64 6) Thread local storage may not be viewed as part of the root set by the | |
65 collector. This probably depends on the linuxthreads version. For the | |
66 time being, any collectable memory referenced by thread local storage should | |
67 also be referenced from elsewhere, or be allocated as uncollectable. | |
68 (This is really a bug that should be fixed somehow.) | |
69 | |
70 | |
71 M68K LINUX: | |
72 (From Richard Zidlicky) | |
73 The bad news is that it can crash every linux-m68k kernel on a 68040, | |
74 so an additional test is needed somewhere on startup. I have meanwhile | |
75 patches to correct the problem in 68040 buserror handler but it is not | |
76 yet in any standard kernel. | |
77 | |
78 Here is a simple test program to detect whether the kernel has the | |
79 problem. It could be run as a separate check in configure or tested | |
80 upon startup. If it fails (return !0) than mprotect can't be used | |
81 on that system. | |
82 | |
83 /* | |
84 * test for bug that may crash 68040 based Linux | |
85 */ | |
86 | |
87 #include <sys/mman.h> | |
88 #include <signal.h> | |
89 #include <unistd.h> | |
90 #include <stdio.h> | |
91 #include <stdlib.h> | |
92 | |
93 | |
94 char *membase; | |
95 int pagesize=4096; | |
96 int pageshift=12; | |
97 int x_taken=0; | |
98 | |
99 int sighandler(int sig) | |
100 { | |
101 mprotect(membase,pagesize,PROT_READ|PROT_WRITE); | |
102 x_taken=1; | |
103 } | |
104 | |
105 main() | |
106 { | |
107 long l; | |
108 | |
109 signal(SIGSEGV,sighandler); | |
110 l=(long)mmap(NULL,pagesize,PROT_READ,MAP_PRIVATE | MAP_ANON,-1,0); | |
111 if (l==-1) | |
112 { | |
113 perror("mmap/malloc"); | |
114 abort(); | |
115 } | |
116 membase=(char*)l; | |
117 *(long*)(membase+sizeof(long))=123456789; | |
118 if (*(long*)(membase+sizeof(long)) != 123456789 ) | |
119 { | |
120 fprintf(stderr,"writeback failed !\n"); | |
121 exit(1); | |
122 } | |
123 if (!x_taken) | |
124 { | |
125 fprintf(stderr,"exception not taken !\n"); | |
126 exit(1); | |
127 } | |
128 fprintf(stderr,"vmtest Ok\n"); | |
129 exit(0); | |
130 } | |
131 | |
132 |