mono/linux-packaging-mono
0
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Imported Upstream version 3.6.0

Browse Source 
Former-commit-id: da6be194a6b1221998fc28233f2503bd61dd9d14
This commit is contained in:
Jo Shields
2014-08-13 10:39:27 +01:00
commit a575963da9
50588 changed files with 8155799 additions and 0 deletions
Download Patch File Download Diff File Expand all files Collapse all files

27
libgc/doc/Makefile.am Normal file
View File

@@ -0,0 +1,27 @@
#
#
# THIS MATERIAL IS PROVIDED AS IS, WITH ABSOLUTELY NO WARRANTY EXPRESSED
# OR IMPLIED. ANY USE IS AT YOUR OWN RISK.
#
# Permission is hereby granted to use or copy this program
# for any purpose, provided the above notices are retained on all copies.
# Permission to modify the code and to distribute modified code is granted,
# provided the above notices are retained, and a notice that the code was
# modified is included with the above copyright notice.
#
# Modified by: Grzegorz Jakacki <jakacki at acm dot org>
## Process this file with automake to produce Makefile.in.
# installed documentation
#
dist_pkgdata_DATA = barrett_diagram debugging.html gc.man \
gcdescr.html README README.amiga README.arm.cross \
README.autoconf README.changes README.contributors \
README.cords README.DGUX386 README.dj README.environment \
README.ews4800 README.hp README.linux README.Mac \
README.MacOSX README.macros README.OS2 README.rs6000 \
README.sgi README.solaris2 README.uts README.win32 \
tree.html leak.html gcinterface.html scale.html \
README.darwin simple_example.html

527
libgc/doc/Makefile.in Normal file
View File

File diff suppressed because it is too large Load Diff

622
libgc/doc/README Normal file
View File

File diff suppressed because it is too large Load Diff

215
libgc/doc/README.DGUX386 Normal file
View File

@@ -0,0 +1,215 @@
Garbage Collector (parallel iversion) for ix86 DG/UX Release R4.20MU07
*READ* the file README.QUICK.
You need the GCC-3.0.3 rev (DG/UX) compiler to build this tree.
This compiler has the new "dgux386" threads package implemented.
It also supports the switch "-pthread" needed to link correctly
the DG/UX's -lrte -lthread with -lgcc and the system's -lc.
Finally we support parralleli-mark for the SMP DG/UX machines.
To build the garbage collector do:
./configure --enable-parallel-mark
make
make gctest
Before you run "gctest" you need to set your LD_LIBRARY_PATH
correctly so that "gctest" can find the shared library libgc.
Alternatively you can do a configuration
./configure --enable-parallel-mark --disable-shared
to build only the static version of libgc.
To enable debugging messages please do:
1) Add the "--enable-full-debug" flag during configuration.
2) Edit the file linux-threads.c and uncommnect the line:
/* #define DEBUG_THREADS 1 */ to --->
#define DEBUG_THREADS 1
Then give "make" as usual.
In a machine with 4 CPUs (my own machine) the option parallel
mark (aka --enable-parallel-mark) makes a BIG difference.
Takis Psarogiannakopoulos
University of Cambridge
Centre for Mathematical Sciences
Department of Pure Mathematics
Wilberforce Road
Cambridge CB3 0WB ,UK , <takis@XFree86.Org>
January 2002
Note (HB):
The integration of this patch is currently not complete.
The following patches against 6.1alpha3 where hard to move
to alpha4, and are not integrated. There may also be minor
problems with stylistic corrections made by me.
--- ltconfig.ORIG Mon Jan 28 20:22:18 2002
+++ ltconfig Mon Jan 28 20:44:00 2002
@@ -689,6 +689,11 @@
pic_flag=-Kconform_pic
fi
;;
+ dgux*)
+ pic_flag='-fPIC'
+ link_static='-Bstatic'
+ wl='-Wl,'
+ ;;
*)
pic_flag='-fPIC'
;;
@@ -718,6 +723,12 @@
# We can build DLLs from non-PIC.
;;
+ dgux*)
+ pic_flag='-KPIC'
+ link_static='-Bstatic'
+ wl='-Wl,'
+ ;;
+
osf3* | osf4* | osf5*)
# All OSF/1 code is PIC.
wl='-Wl,'
@@ -1154,6 +1165,22 @@
fi
;;
+ dgux*)
+ ld_shlibs=yes
+ # For both C/C++ ommit the deplibs. This is because we relying on the fact
+ # that compilation of execitables will put them in correct order
+ # in any case and sometimes are wrong when listed as deplibs (or missing some deplibs)
+ # However when GNU ld and --whole-archive needs to be used we have the problem
+ # that if the -fPIC *_s.a archive is linked through deplibs list we ommiting crucial
+ # .lo/.o files from the created shared lib. This I think is not the case here.
+ archive_cmds='$CC -shared -h $soname -o $lib $libobjs $linkopts'
+ thread_safe_flag_spec='-pthread'
+ wlarc=
+ hardcode_libdir_flag_spec='-L$libdir'
+ hardcode_shlibpath_var=no
+ ac_cv_archive_cmds_needs_lc=no
+ ;;
+
cygwin* | mingw*)
# hardcode_libdir_flag_spec is actually meaningless, as there is
# no search path for DLLs.
@@ -1497,7 +1524,7 @@
;;
dgux*)
- archive_cmds='$LD -G -h $soname -o $lib $libobjs $deplibs $linkopts'
+ archive_cmds='$CC -shared -h $soname -o $lib $libobjs $linkopts'
hardcode_libdir_flag_spec='-L$libdir'
hardcode_shlibpath_var=no
;;
@@ -2092,12 +2119,17 @@
;;
dgux*)
- version_type=linux
+ version_type=dgux
need_lib_prefix=no
need_version=no
- library_names_spec='${libname}${release}.so$versuffix ${libname}${release}.so$major $libname.so'
- soname_spec='${libname}${release}.so$major'
+ library_names_spec='$libname.so$versuffix'
+ soname_spec='$libname.so$versuffix'
shlibpath_var=LD_LIBRARY_PATH
+ thread_safe_flag_spec='-pthread'
+ wlarc=
+ hardcode_libdir_flag_spec='-L$libdir'
+ hardcode_shlibpath_var=no
+ ac_cv_archive_cmds_needs_lc=no
;;
sysv4*MP*)
--- ltmain.sh.ORIG Mon Jan 28 20:31:18 2002
+++ ltmain.sh Tue Jan 29 00:11:29 2002
@@ -1072,11 +1072,38 @@
esac
;;
+ -thread*)
+ # DG/UX GCC 2.95.x, 3.x.x rev (DG/UX) links -lthread
+ # with the switch -threads
+ if test "$arg" = "-threads"; then
+ case "$host" in
+ i[3456]86-*-dgux*)
+ deplibs="$deplibs $arg"
+ continue
+ ;;
+ esac
+ fi
+ ;;
+
+ -pthread*)
+ # DG/UX GCC 2.95.x, 3.x.x rev (DG/UX) links -lthread
+ # with the switch -pthread
+ if test "$arg" = "-pthread"; then
+ case "$host" in
+ i[3456]86-*-dgux*)
+ deplibs="$deplibs $arg"
+ continue
+ ;;
+ esac
+ fi
+ ;;
+
-l*)
if test "$arg" = "-lc"; then
case "$host" in
- *-*-cygwin* | *-*-mingw* | *-*-os2* | *-*-beos*)
+ *-*-cygwin* | *-*-mingw* | *-*-os2* | *-*-beos* | i[3456]86-*-dgux*)
# These systems don't actually have c library (as such)
+ # It is wrong in DG/UX to add -lc when creating shared/dynamic objs/libs
continue
;;
esac
@@ -1248,6 +1275,12 @@
temp_deplibs=
for deplib in $dependency_libs; do
case "$deplib" in
+ -thread*)
+ temp_deplibs="$temp_deplibs $deplib"
+ ;;
+ -pthread)
+ temp_deplibs="$temp_deplibs $deplib"
+ ;;
-R*) temp_xrpath=`$echo "X$deplib" | $Xsed -e 's/^-R//'`
case " $rpath $xrpath " in
*" $temp_xrpath "*) ;;
@@ -1709,6 +1742,13 @@
done
;;
+ dgux)
+ # Leave mostly blank for DG/UX
+ major=
+ versuffix=".$current.$revision";
+ verstring=
+ ;;
+
linux)
major=.`expr $current - $age`
versuffix="$major.$age.$revision"
@@ -1792,8 +1832,9 @@
dependency_libs="$deplibs"
case "$host" in
- *-*-cygwin* | *-*-mingw* | *-*-os2* | *-*-beos*)
+ *-*-cygwin* | *-*-mingw* | *-*-os2* | *-*-beos* | i[3456]86-*-dgux*)
# these systems don't actually have a c library (as such)!
+ # It is wrong in DG/UX to add -lc when creating shared/dynamic objs/libs
;;
*)
# Add libc to deplibs on all other systems.

385
libgc/doc/README.Mac Normal file
View File

@@ -0,0 +1,385 @@
Patrick Beard's Notes for building GC v4.12 with CodeWarrior Pro 2:
----------------------------------------------------------------------------
The current build environment for the collector is CodeWarrior Pro 2.
Projects for CodeWarrior Pro 2 (and for quite a few older versions)
are distributed in the file Mac_projects.sit.hqx. The project file
:Mac_projects:gc.prj builds static library versions of the collector.
:Mac_projects:gctest.prj builds the GC test suite.
Configuring the collector is still done by editing the files
:Mac_files:MacOS_config.h and :Mac_files:MacOS_Test_config.h.
Lars Farm's suggestions on building the collector:
----------------------------------------------------------------------------
Garbage Collection on MacOS - a manual 'MakeFile'
-------------------------------------------------
Project files and IDE's are great on the Macintosh, but they do have
problems when used as distribution media. This note tries to provide
porting instructions in pure TEXT form to avoid those problems. A manual
'makefile' if you like.
GC version: 4.12a2
Codewarrior: CWPro1
date: 18 July 1997
The notes may or may not apply to earlier or later versions of the
GC/CWPro. Actually, they do apply to earlier versions of both except that
until recently a project could only build one target so each target was a
separate project. The notes will most likely apply to future versions too.
Possibly with minor tweaks.
This is just to record my experiences. These notes do not mean I now
provide a supported port of the GC to MacOS. It works for me. If it works
for you, great. If it doesn't, sorry, try again...;-) Still, if you find
errors, please let me know.
mailto: lars.farm@ite.mh.se
address: Lars Farm
Kr<4B>nv<6E>gen 33b
856 44 Sundsvall
Sweden
Porting to MacOS is a bit more complex than it first seems. Which MacOS?
68K/PowerPC? Which compiler? Each supports both 68K and PowerPC and offer a
large number of (unique to each environment) compiler settings. Each
combination of compiler/68K/PPC/settings require a unique combination of
standard libraries. And the IDE's does not select them for you. They don't
even check that the library is built with compatible setting and this is
the major source of problems when porting the GC (and otherwise too).
You will have to make choices when you configure the GC. I've made some
choices here, but there are other combinations of settings and #defines
that work too.
As for target settings the major obstacles may be:
- 68K Processor: check "4-byte Ints".
- PPC Processor: uncheck "Store Static Data in TOC".
What you need to do:
===================
1) Build the GC as a library
2) Test that the library works with 'test.c'.
3) Test that the C++ interface 'gc_cpp.cc/h' works with 'test_cpp.cc'.
1) The Libraries:
=================
I made one project with four targets (68K/PPC tempmem or appheap). One target
will suffice if you're able to decide which one you want. I wasn't...
Codewarrior allows a large number of compiler/linker settings. I used these:
Settings shared by all targets:
------------------------------
o Access Paths:
- User Paths: the GC folder
- System Paths: {Compiler}:Metrowerks Standard Library:
{Compiler}:MacOS Support:Headers:
{Compiler}:MacOS Support:MacHeaders:
o C/C++ language:
- inlining: normal
- direct to SOM: off
- enable/check: exceptions, RTTI, bool (and if you like pool strings)
PowerPC target settings
-----------------------
o Target Settings:
- name of target
- MacOS PPC Linker
o PPC Target
- name of library
o C/C++ language
- prefix file as described below
o PPC Processor
- Struct Alignment: PowerPC
- uncheck "Store Static Data in TOC" -- important!
I don't think the others matter, I use full optimization and its ok
o PPC Linker
- Factory Settings (SYM file with full paths, faster linking, dead-strip
static init, Main: __start)
68K target settings
-------------------
o Target Settings:
- name of target
- MacOS 68K Linker
o 68K Target
- name of library
- A5 relative data
o C/C++ language
- prefix file as described below
o 68K Processor
- Code model: smart
- Struct alignment: 68K
- FP: SANE
- enable 4-Byte Ints -- important!
I don't think the others matter. I selected...
- enable: 68020
- enable: global register allocation
o IR Optimizer
- enable: Optimize Space, Optimize Speed
I suppose the others would work too, but haven't tried...
o 68K Linker
- Factory Settings (New Style MacsBug,SYM file with full paths,
A6 Frames, fast link, Merge compiler glue into segment 1,
dead-strip static init)
Prefix Files to configure the GC sources
----------------------------------------
The Codewarrior equivalent of commandline compilers -DNAME=X is to use
prefix-files. A TEXT file that is automatically #included before the first byte
of every source file. I used these:
---- ( cut here ) ---- gc_prefix_tempmem.h -- 68K and PPC -----
#include "gc_prefix_common.h"
#undef USE_TEMPORARY_MEMORY
#define USE_TEMPORARY_MEMORY
---- ( cut here ) ---- gc_prefix_appmem.h -- 68K and PPC -----
#include "gc_prefix_common.h"
#undef USE_TEMPORARY_MEMORY
// #define USE_TEMPORARY_MEMORY
---- ( cut here ) ---- gc_prefix_common.h --------------------
// gc_prefix_common.h
// ------------------
// Codewarrior prefix file to configure the GC libraries
//
// prefix files are the Codewarrior equivalent of the
// command line option -Dname=x frequently seen in makefiles
#if !__MWERKS__
#error only tried this with Codewarrior
#endif
#if macintosh
#define MSL_USE_PRECOMPILED_HEADERS 0
#include <ansi_prefix.mac.h>
#ifndef __STDC__
#define __STDC__ 0
#endif
// See list of #defines to configure the library in: 'MakeFile'
// see also README
#define SILENT // no collection messages. In case
// of trouble you might want this off
#define ALL_INTERIOR_POINTERS // follows interior pointers.
//#define DONT_ADD_BYTE_AT_END // disables the padding if defined.
//#define SMALL_CONFIG // whether to use a smaller heap.
#define NO_SIGNALS // signals aren't real on the Macintosh.
#define ATOMIC_UNCOLLECTABLE // GC_malloc_atomic_uncollectable()
// define either or none as per personal preference
// used in malloc.c
#define REDIRECT_MALLOC GC_malloc
//#define REDIRECT_MALLOC GC_malloc_uncollectable
// if REDIRECT_MALLOC is #defined make sure that the GC library
// is listed before the ANSI/ISO libs in the Codewarrior
// 'Link order' panel
//#define IGNORE_FREE
// mac specific configs
//#define USE_TEMPORARY_MEMORY // use Macintosh temporary memory.
//#define SHARED_LIBRARY_BUILD // build for use in a shared library.
#else
// could build Win32 here too, or in the future
// Rhapsody PPC-mach, Rhapsody PPC-MacOS,
// Rhapsody Intel-mach, Rhapsody Intel-Win32,...
// ... ugh this will get messy ...
#endif
// make sure ints are at least 32-bit
// ( could be set to 16-bit by compiler settings (68K) )
struct gc_private_assert_intsize_{ char x[ sizeof(int)>=4 ? 1 : 0 ]; };
#if __powerc
#if __option(toc_data)
#error turn off "store static data in TOC" when using GC
// ... or find a way to add TOC to the root set...(?)
#endif
#endif
---- ( cut here ) ---- end of gc_prefix_common.h -----------------
Files to build the GC libraries:
--------------------------------
allchblk.c
alloc.c
blacklst.c
checksums.c
dbg_mlc.c
finalize.c
headers.c
mach_dep.c
MacOS.c -- contains MacOS code
malloc.c
mallocx.c
mark.c
mark_rts.c
misc.c
new_hblk.c
obj_map.c
os_dep.c -- contains MacOS code
ptr_chck.c
reclaim.c
stubborn.c
typd_mlc.c
gc++.cc -- this is 'gc_cpp.cc' with less 'inline' and
-- throw std::bad_alloc when out of memory
-- gc_cpp.cc works just fine too
2) Test that the library works with 'test.c'.
=============================================
The test app is just an ordinary ANSI-C console app. Make sure settings
match the library you're testing.
Files
-----
test.c
the GC library to test -- link order before ANSI libs
suitable Mac+ANSI libraries
prefix:
------
---- ( cut here ) ---- gc_prefix_testlib.h -- all libs -----
#define MSL_USE_PRECOMPILED_HEADERS 0
#include <ansi_prefix.mac.h>
#undef NDEBUG
#define ALL_INTERIOR_POINTERS /* for GC_priv.h */
---- ( cut here ) ----
3) Test that the C++ interface 'gc_cpp.cc/h' works with 'test_cpp.cc'.
The test app is just an ordinary ANSI-C console app. Make sure settings match
the library you're testing.
Files
-----
test_cpp.cc
the GC library to test -- link order before ANSI libs
suitable Mac+ANSI libraries
prefix:
------
same as for test.c
For convenience I used one test-project with several targets so that all
test apps are build at once. Two for each library to test: test.c and
gc_app.cc. When I was satisfied that the libraries were ok. I put the
libraries + gc.h + the c++ interface-file in a folder that I then put into
the MSL hierarchy so that I don't have to alter access-paths in projects
that use the GC.
After that, just add the proper GC library to your project and the GC is in
action! malloc will call GC_malloc and free GC_free, new/delete too. You
don't have to call free or delete. You may have to be a bit cautious about
delete if you're freeing other resources than RAM. See gc_cpp.h. You can
also keep coding as always with delete/free. That works too. If you want,
"include <gc.h> and tweak it's use a bit.
Symantec SPM
============
It has been a while since I tried the GC in SPM, but I think that the above
instructions should be sufficient to guide you through in SPM too. SPM
needs to know where the global data is. Use the files 'datastart.c' and
'dataend.c'. Put 'datastart.c' at the top of your project and 'dataend.c'
at the bottom of your project so that all data is surrounded. This is not
needed in Codewarrior because it provides intrinsic variables
__datastart__, __data_end__ that wraps all globals.
Source Changes (GC 4.12a2)
==========================
Very few. Just one tiny in the GC, not strictly needed.
- MacOS.c line 131 in routine GC_MacFreeTemporaryMemory()
change # if !defined(SHARED_LIBRARY_BUILD)
to # if !defined(SILENT) && !defined(SHARED_LIBRARY_BUILD)
To turn off a message when the application quits (actually, I faked
this change by #defining SHARED_LIBRARY_BUILD in a statically linked
library for more than a year without ill effects but perhaps this is
better).
- test_cpp.cc
made the first lines of main() look like this:
------------
int main( int argc, char* argv[] ) {
#endif
#if macintosh // MacOS
char* argv_[] = {"test_cpp","10"}; // doesn't
argv=argv_; // have a
argc = sizeof(argv_)/sizeof(argv_[0]); // commandline
#endif //
int i, iters, n;
# ifndef __GNUC__
alloc dummy_to_fool_the_compiler_into_doing_things_it_currently_cant_handle;
------------
- config.h [now gcconfig.h]
__MWERKS__ does not have to mean MACOS. You can use Codewarrior to
build a Win32 or BeOS library and soon a Rhapsody library. You may
have to change that #if...
It worked for me, hope it works for you.
Lars Farm
18 July 1997
----------------------------------------------------------------------------
Patrick Beard's instructions (may be dated):
v4.3 of the collector now runs under Symantec C++/THINK C v7.0.4, and
Metrowerks C/C++ v4.5 both 68K and PowerPC. Project files are provided
to build and test the collector under both development systems.
Configuration
-------------
To configure the collector, under both development systems, a prefix file
is used to set preprocessor directives. This file is called "MacOS_config.h".
Also to test the collector, "MacOS_Test_config.h" is provided.
Testing
-------
To test the collector (always a good idea), build one of the gctest projects,
gctest.<2E> (Symantec C++/THINK C), mw/gctest.68K.<2E>, or mw/gctest.PPC.<2E>. The
test will ask you how many times to run; 1 should be sufficient.
Building
--------
For your convenience project files for the major Macintosh development
systems are provided.
For Symantec C++/THINK C, you must build the two projects gclib-1.<2E> and
gclib-2.<2E>. It has to be split up because the collector has more than 32k
of static data and no library can have more than this in the Symantec
environment. (Future versions will probably fix this.)
For Metrowerks C/C++ 4.5 you build gc.68K.<2E>/gc.PPC.<2E> and the result will
be a library called gc.68K.lib/gc.PPC.lib.
Using
-----
Under Symantec C++/THINK C, you can just add the gclib-1.<2E> and gclib-2.<2E>
projects to your own project. Under Metrowerks, you add gc.68K.lib or
gc.PPC.lib and two additional files. You add the files called datastart.c
and dataend.c to your project, bracketing all files that use the collector.
See mw/gctest.<2E> for an example.
Include the projects/libraries you built above into your own project,
#include "gc.h", and call GC_malloc. You don't have to call GC_free.
Patrick C. Beard
January 4, 1995

1
libgc/doc/README.MacOSX Normal file
View File

@@ -0,0 +1 @@
See README.darwin for the latest Darwin/MacOSX information.

6
libgc/doc/README.OS2 Normal file
View File

@@ -0,0 +1,6 @@
The code assumes static linking, and a single thread. The editor de has
not been ported. The cord test program has. The supplied OS2_MAKEFILE
assumes the IBM C Set/2 environment, but the code shouldn't.
Since we haven't figured out hoe to do perform partial links or to build static
libraries, clients currently need to link against a long list of executables.

322
libgc/doc/README.amiga Normal file
View File

@@ -0,0 +1,322 @@
===========================================================================
Kjetil S. Matheussen's notes (28-11-2000)
===========================================================================
Compiles under SAS/C again. Should allso still compile under other
amiga compilers without big changes. I haven't checked if it still
works under gcc, because I don't have gcc for amiga. But I have
updated 'Makefile', and hope it compiles fine.
WHATS NEW:
1.
Made a pretty big effort in preventing GCs allocating-functions from returning
chip-mem.
The lower part of the new file AmigaOS.c does this in various ways, mainly by
wrapping GC_malloc, GC_malloc_atomic, GC_malloc_uncollectable,
GC_malloc_atomic_uncollectable, GC_malloc_stubborn, GC_malloc_ignore_off_page
and GC_malloc_atomic_ignore_off_page. GC_realloc is allso wrapped, but
doesn't do the same effort in preventing to return chip-mem.
Other allocating-functions (f.ex. GC_*_typed_) can probably be
used without any problems, but beware that the warn hook will not be called.
In case of problems, don't define GC_AMIGA_FASTALLOC.
Programs using more time actually using the memory allocated
(instead of just allocate and free rapidly) have
the most to earn on this, but even gctest now normally runs twice
as fast and uses less memory, on my poor 8MB machine.
The changes have only effect when there is no more
fast-mem left. But with the way GC works, it
could happen quite often. Beware that an atexit handler had to be added,
so using the abort() function will make a big memory-loss.
If you absolutely must call abort() instead of exit(), try calling
the GC_amiga_free_all_mem function before abort().
New amiga-spesific compilation flags:
GC_AMIGA_FASTALLOC - By NOT defining this option, GC will work like before,
it will not try to force fast-mem out of the OS, and
it will use normal calloc for allocation, and the rest
of the following flags will have no effect.
GC_AMIGA_ONLYFAST - Makes GC never to return chip-mem. GC_AMIGA_RETRY have
no effect if this flag is set.
GC_AMIGA_GC - If gc returns NULL, do a GC_gcollect, and try again. This
usually is a success with the standard GC configuration.
It is allso the most important flag to set to prevent
GC from returning chip-mem. Beware that it slows down a lot
when a program is rapidly allocating/deallocating when
theres either very little fast-memory left or verly little
chip-memory left. Its not a very common situation, but gctest
sometimes (very rare) use many minutes because of this.
GC_AMIGA_RETRY - If gc succeed allocating memory, but it is chip-mem,
try again and see if it is fast-mem. Most of the time,
it will actually return fast-mem for the second try.
I have set max number of retries to 9 or size/5000. You
can change this if you like. (see GC_amiga_rec_alloc())
GC_AMIGA_PRINTSTATS - Gather some statistics during the execution of a
program, and prints out the info when the atexit-handler
is called.
My reccomendation is to set all this flags, except GC_AMIGA_PRINTSTATS and
GC_AMIGA_ONLYFAST.
If your program demands high response-time, you should
not define GC_AMIGA_GC, and possible allso define GC_AMIGA_ONLYFAST.
GC_AMIGA_RETRY does not seem to slow down much.
Allso, when compiling up programs, and GC_AMIGA_FASTALLOC was not defined when
compilling gc, you can define GC_AMIGA_MAKINGLIB to avoid having these allocation-
functions wrapped. (see gc.h)
Note that GC_realloc must not be called before any of
the other above mentioned allocating-functions have been called. (shouldn't be
any programs doing so either, I hope).
Another note. The allocation-function is wrapped when defining
GC_AMIGA_FASTALLOC by letting the function go thru the new
GC_amiga_allocwrapper_do function-pointer (see gc.h). Means that
sending function-pointers, such as GC_malloc, GC_malloc_atomic, etc.,
for later to be called like f.ex this, (*GC_malloc_functionpointer)(size),
will not wrap the function. This is normally not a big problem, unless
all allocation function is called like this, which will cause the
atexit un-allocating function never to be called. Then you either
have to manually add the atexit handler, or call the allocation-
functions function-pointer functions like this;
(*GC_amiga_allocwrapper_do)(size,GC_malloc_functionpointer).
There are probably better ways this problem could be handled, unfortunately,
I didn't find any without rewriting or replacing a lot of the GC-code, which
I really didn't want to. (Making new GC_malloc_* functions, and just
define f.ex GC_malloc as GC_amiga_malloc should allso work).
New amiga-spesific function:
void GC_amiga_set_toany(void (*func)(void));
'func' is a function that will be called right before gc has to change
allocation-method from MEMF_FAST to MEMF_ANY. Ie. when it is likely
it will return chip-mem.
2. A few small compiler-spesific additions to make it compile with SAS/C again.
3. Updated and rewritten the smakefile, so that it works again and that
the "unnecesarry" 'SCOPTIONS' files could be removed. Allso included
the cord-smakefile stuff in the main smakefile, so that the cord smakefile
could be removed too. By writing smake -f Smakefile.smk, both gc.lib and
cord.lib will be made.
STILL MISSING:
Programs can not be started from workbench, at least not for SAS/C. (Martin
Tauchmanns note about that it now works with workbench is definitely wrong
when concerning SAS/C). I guess it works if you use the old "#if 0'ed"-code,
but I haven't tested it. I think the reason for MT to replace the
"#if 0'ed"-code was only because it was a bit to SAS/C-spesific. But I
don't know. An iconx-script solves this problem anyway.
BEWARE!
-To run gctest, set the stack to around 200000 bytes first.
-SAS/C-spesific: cord will crash if you compile gc.lib with
either parm=reg or parm=both. (missing legal prototypes for
function-pointers someplace is the reason I guess.).
tested with software: Radium, http://www.stud.ifi.uio.no/~ksvalast/radium/
tested with hardware: MC68060
-ksvalast@ifi.uio.no
===========================================================================
Martin Tauchmann's notes (1-Apr-99)
===========================================================================
Works now, also with the GNU-C compiler V2.7.2.1. <ftp://ftp.unina.it/pub/amiga/geekgadgets/amiga/m68k/snapshots/971125/amiga-bin/>
Modify the `Makefile`
CC=cc $(ABI_FLAG)
to
CC=gcc $(ABI_FLAG)
TECHNICAL NOTES
- `GC_get_stack_base()`, `GC_register_data_segments()` works now with every
C compiler; also Workbench.
- Removed AMIGA_SKIP_SEG, but the Code-Segment must not be scanned by GC.
PROBLEMS
- When the Linker, does`t merge all Code-Segments to an single one. LD of GCC
do it always.
- With ixemul.library V47.3, when an GC program launched from another program
(example: `Make` or `if_mach M68K AMIGA gctest`), `GC_register_data_segments()`
found the Segment-List of the caller program.
Can be fixed, if the run-time initialization code (for C programs, usually *crt0*)
support `__data` and `__bss`.
- PowerPC Amiga currently not supported.
- Dynamic libraries (dyn_load.c) not supported.
TESTED WITH SOFTWARE
`Optimized Oberon 2 C` (oo2c) <http://cognac.informatik.uni-kl.de/download/index.html>
TESTED WITH HARDWARE
MC68030
CONTACT
Please, contact me at <martintauchmann@bigfoot.com>, when you change the
Amiga port. <http://martintauchmann.home.pages.de>
===========================================================================
Michel Schinz's notes
===========================================================================
WHO DID WHAT
The original Amiga port was made by Jesper Peterson. I (Michel Schinz)
modified it slightly to reflect the changes made in the new official
distributions, and to take advantage of the new SAS/C 6.x features. I also
created a makefile to compile the "cord" package (see the cord
subdirectory).
TECHNICAL NOTES
In addition to Jesper's notes, I have the following to say:
- Starting with version 4.3, gctest checks to see if the code segment is
added to the root set or not, and complains if it is. Previous versions
of this Amiga port added the code segment to the root set, so I tried to
fix that. The only problem is that, as far as I know, it is impossible to
know which segments are code segments and which are data segments (there
are indeed solutions to this problem, like scanning the program on disk
or patch the LoadSeg functions, but they are rather complicated). The
solution I have chosen (see os_dep.c) is to test whether the program
counter is in the segment we are about to add to the root set, and if it
is, to skip the segment. The problems are that this solution is rather
awkward and that it works only for one code segment. This means that if
your program has more than one code segment, all of them but one will be
added to the root set. This isn't a big problem in fact, since the
collector will continue to work correctly, but it may be slower.
Anyway, the code which decides whether to skip a segment or not can be
removed simply by not defining AMIGA_SKIP_SEG. But notice that if you do
so, gctest will complain (it will say that "GC_is_visible produced wrong
failure indication"). However, it may be useful if you happen to have
pointers stored in a code segment (you really shouldn't).
If anyone has a good solution to the problem of finding, when a program
is loaded in memory, whether a segment is a code or a data segment,
please let me know.
PROBLEMS
If you have any problem with this version, please contact me at
schinz@alphanet.ch (but do *not* send long files, since we pay for
every mail!).
===========================================================================
Jesper Peterson's notes
===========================================================================
ADDITIONAL NOTES FOR AMIGA PORT
These notes assume some familiarity with Amiga internals.
WHY I PORTED TO THE AMIGA
The sole reason why I made this port was as a first step in getting
the Sather(*) language on the Amiga. A port of this language will
be done as soon as the Sather 1.0 sources are made available to me.
Given this motivation, the garbage collection (GC) port is rather
minimal.
(*) For information on Sather read the comp.lang.sather newsgroup.
LIMITATIONS
This port assumes that the startup code linked with target programs
is that supplied with SAS/C versions 6.0 or later. This allows
assumptions to be made about where to find the stack base pointer
and data segments when programs are run from WorkBench, as opposed
to running from the CLI. The compiler dependent code is all in the
GC_get_stack_base() and GC_register_data_segments() functions, but
may spread as I add Amiga specific features.
Given that SAS/C was assumed, the port is set up to be built with
"smake" using the "SMakefile". Compiler options in "SCoptions" can
be set with "scopts" program. Both "smake" and "scopts" are part of
the SAS/C commercial development system.
In keeping with the porting philosophy outlined above, this port
will not behave well with Amiga specific code. Especially not inter-
process comms via messages, and setting up public structures like
Intuition objects or anything else in the system lists. For the
time being the use of this library is limited to single threaded
ANSI/POSIX compliant or near-complient code. (ie. Stick to stdio
for now). Given this limitation there is currently no mechanism for
allocating "CHIP" or "PUBLIC" memory under the garbage collector.
I'll add this after giving it considerable thought. The major
problem is the entire physical address space may have to me scanned,
since there is no telling who we may have passed memory to.
If you allocate your own stack in client code, you will have to
assign the pointer plus stack size to GC_stackbottom.
The initial stack size of the target program can be compiled in by
setting the __stack symbol (see SAS documentaion). It can be over-
ridden from the CLI by running the AmigaDOS "stack" program, or from
the WorkBench by setting the stack size in the tool types window.
SAS/C COMPILER OPTIONS (SCoptions)
You may wish to check the "CPU" code option is appropriate for your
intended target system.
Under no circumstances set the "StackExtend" code option in either
compiling the library or *ANY* client code.
All benign compiler warnings have been suppressed. These mainly
involve lack of prototypes in the code, and dead assignments
detected by the optimizer.
THE GOOD NEWS
The library as it stands is compatible with the GigaMem commercial
virtual memory software, and probably similar PD software.
The performance of "gctest" on an Amiga 2630 (68030 @ 25Mhz)
compares favourably with an HP9000 with similar architecture (a 325
with a 68030 I think).
-----------------------------------------------------------------------
The Amiga port has been brought to you by:
Jesper Peterson.
jep@mtiame.mtia.oz.au (preferred, but 1 week turnaround)
jep@orca1.vic.design.telecom.au (that's orca<one>, 1 day turnaround)
At least one of these addresses should be around for a while, even
though I don't work for either of the companies involved.

68
libgc/doc/README.arm.cross Executable file
View File

@@ -0,0 +1,68 @@
From: Margaret Fleck
Here's the key details of what worked for me, in case anyone else needs them.
There may well be better ways to do some of this, but ....
-- Margaret
The badge4 has a StrongArm-1110 processor and a StrongArm-1111 coprocessor.
Assume that the garbage collector distribution is unpacked into /home/arm/gc6.0,
which is visible to both the ARM machine and a linux desktop (e.g. via NFS mounting).
Assume that you have a file /home/arm/config.site with contents something like the
example attached below. Notice that our local ARM toolchain lives in
/skiff/local.
Go to /home/arm/gc6.0 directory. Do
CONFIG_SITE=/home/arm/config.site ./configure --target=arm-linux
--prefix=/home/arm/gc6.0
On your desktop, do:
make
make install
The main garbage collector library should now be in ../gc6.0/lib/libgc.so.
To test the garbage collector, first do the following on your desktop
make gctest
./gctest
Then do the following on the ARM machine
cd .libs
./lt-gctest
Do not try to do "make test" (the usual way of running the test
program). This does not work and seems to erase some of the important
files.
The gctest program claims to have succeeded. Haven't run any further tests
with it, though I'll be doing so in the near future.
-------------------------------
# config.site for configure
# Modified from the one provided by Bradley D. LaRonde
# Edited by Andrej Cedilnik <acedil1@csee.umbc.edu>
# Used some of solutions by Tilman Vogel <Tilman.Vogel@web.de>
# Ported for iPAQ Familiar by Oliver Kurth <oliver.kurth@innominate.com>
# Further modified by Margaret Fleck for the badge4
HOSTCC=gcc
# Names of the cross-compilers
CC=/skiff/local/bin/arm-linux-gcc
CXX=/skiff/local/bin/arm-linux-gcc
# The cross compiler specific options
CFLAGS="-O2 -fno-exceptions"
CXXFLAGS="-O2 -fno-exceptions"
CPPFLAGS="-O2 -fno-exceptions"
LDFLAGS=""
# Some other programs
AR=/skiff/local/bin/arm-linux-ar
RANLIB=/skiff/local/bin/arm-linux-ranlib
NM=/skiff/local/bin/arm-linux-nm
ac_cv_path_NM=/skiff/local/bin/arm-linux-nm
ac_cv_func_setpgrp_void=yes
x_includes=/skiff/local/arm-linux/include/X11
x_libraries=/skiff/local/arm-linux/lib/X11

59
libgc/doc/README.autoconf Normal file
View File

@@ -0,0 +1,59 @@
As of GC6.0alpha8, we attempt to support GNU-style builds based on automake,
autoconf and libtool. This is based almost entirely on Tom Tromey's work
with gcj.
To build and install libraries use
configure; make; make install
The advantages of this process are:
1) It should eventually do a better job of automatically determining the
right compiler to use, etc. It probably already does in some cases.
2) It tries to automatically set a good set of default GC parameters for
the platform (e.g. thread support). It provides an easier way to configure
some of the others.
3) It integrates better with other projects using a GNU-style build process.
4) It builds both dynamic and static libraries.
The known disadvantages are:
1) The build scripts are much more complex and harder to debug (though largely
standard). I don't understand them all, and there's probably lots of redundant
stuff.
2) It probably doesn't work on all Un*x-like platforms yet. It probably will
never work on the rest.
3) The scripts are not yet complete. Some of the standard GNU targets don't
yet work. (Corrections/additions are very welcome.)
The distribution should contain all files needed to run "configure" and "make",
as well as the sources needed to regenerate the derived files. (If I missed
some, please let me know.)
Note that the distribution comes with a "Makefile" which will be overwritten
by "configure" with one that is not at all equiavelent to the original. The
distribution contains a copy of the original "Makefile" in "Makefile.direct".
Important options to configure:
--prefix=PREFIX install architecture-independent files in PREFIX
[/usr/local]
--exec-prefix=EPREFIX install architecture-dependent files in EPREFIX
[same as prefix]
--enable-threads=TYPE choose threading package
--enable-parallel-mark parallelize marking and free list construction
--enable-full-debug include full support for pointer backtracing etc.
Unless --prefix is set (or --exec-prefix or one of the more obscure options),
make install will install libgc.a and libgc.so in /usr/local/bin, which
would typically require the "make install" to be run as root.
Most commonly --enable-threads=posix or will be needed. --enable-parallel-mark
is recommended for multiprocessors if it is supported on the platform.

1
libgc/doc/README.changes.REMOVED.git-id Normal file
View File

@@ -0,0 +1 @@
fa6f279f518a5fac4b4778e9e869e4d82bb0539c

57
libgc/doc/README.contributors Normal file
View File

@@ -0,0 +1,57 @@
This is an attempt to acknowledge early contributions to the garbage
collector. Later contributions should instead be mentioned in
README.changes.
HISTORY -
Early versions of this collector were developed as a part of research
projects supported in part by the National Science Foundation
and the Defense Advance Research Projects Agency.
The garbage collector originated as part of the run-time system for
the Russell programming language implementation. The first version of the
garbage collector was written primarily by Al Demers. It was then refined
and mostly rewritten, primarily by Hans-J. Boehm, at Cornell U.,
the University of Washington, Rice University (where it was first used for
C and assembly code), Xerox PARC, SGI, and HP Labs. However, significant
contributions have also been made by many others.
Some other contributors:
More recent contributors are mentioned in the modification history in
README.changes. My apologies for any omissions.
The SPARC specific code was originally contributed by Mark Weiser.
The Encore Multimax modifications were supplied by
Kevin Kenny (kenny@m.cs.uiuc.edu). The adaptation to the IBM PC/RT is largely
due to Vernon Lee, on machines made available to Rice by IBM.
Much of the HP specific code and a number of good suggestions for improving the
generic code are due to Walter Underwood.
Robert Brazile (brazile@diamond.bbn.com) originally supplied the ULTRIX code.
Al Dosser (dosser@src.dec.com) and Regis Cridlig (Regis.Cridlig@cl.cam.ac.uk)
subsequently provided updates and information on variation between ULTRIX
systems. Parag Patel (parag@netcom.com) supplied the A/UX code.
Jesper Peterson(jep@mtiame.mtia.oz.au), Michel Schinz, and
Martin Tauchmann (martintauchmann@bigfoot.com) supplied the Amiga port.
Thomas Funke (thf@zelator.in-berlin.de(?)) and
Brian D.Carlstrom (bdc@clark.lcs.mit.edu) supplied the NeXT ports.
Douglas Steel (doug@wg.icl.co.uk) provided ICL DRS6000 code.
Bill Janssen (janssen@parc.xerox.com) supplied the SunOS dynamic loader
specific code. Manuel Serrano (serrano@cornas.inria.fr) supplied linux and
Sony News specific code. Al Dosser provided Alpha/OSF/1 code. He and
Dave Detlefs(detlefs@src.dec.com) also provided several generic bug fixes.
Alistair G. Crooks(agc@uts.amdahl.com) supplied the NetBSD and 386BSD ports.
Jeffrey Hsu (hsu@soda.berkeley.edu) provided the FreeBSD port.
Brent Benson (brent@jade.ssd.csd.harris.com) ported the collector to
a Motorola 88K processor running CX/UX (Harris NightHawk).
Ari Huttunen (Ari.Huttunen@hut.fi) generalized the OS/2 port to
nonIBM development environments (a nontrivial task).
Patrick Beard (beard@cs.ucdavis.edu) provided the initial MacOS port.
David Chase, then at Olivetti Research, suggested several improvements.
Scott Schwartz (schwartz@groucho.cse.psu.edu) supplied some of the
code to save and print call stacks for leak detection on a SPARC.
Jesse Hull and John Ellis supplied the C++ interface code.
Zhong Shao performed much of the experimentation that led to the
current typed allocation facility. (His dynamic type inference code hasn't
made it into the released version of the collector, yet.)

53
libgc/doc/README.cords Normal file
View File

@@ -0,0 +1,53 @@
Copyright (c) 1993-1994 by Xerox Corporation. All rights reserved.
THIS MATERIAL IS PROVIDED AS IS, WITH ABSOLUTELY NO WARRANTY EXPRESSED
OR IMPLIED. ANY USE IS AT YOUR OWN RISK.
Permission is hereby granted to use or copy this program
for any purpose, provided the above notices are retained on all copies.
Permission to modify the code and to distribute modified code is granted,
provided the above notices are retained, and a notice that the code was
modified is included with the above copyright notice.
Please send bug reports to Hans-J. Boehm (Hans_Boehm@hp.com or
boehm@acm.org).
This is a string packages that uses a tree-based representation.
See cord.h for a description of the functions provided. Ec.h describes
"extensible cords", which are essentially output streams that write
to a cord. These allow for efficient construction of cords without
requiring a bound on the size of a cord.
More details on the data structure can be found in
Boehm, Atkinson, and Plass, "Ropes: An Alternative to Strings",
Software Practice and Experience 25, 12, December 1995, pp. 1315-1330.
A fundamentally similar "rope" data structure is also part of SGI's standard
template library implementation, and its descendents, which include the
GNU C++ library. That uses reference counting by default.
There is a short description of that data structure at
http://reality.sgi.com/boehm/ropeimpl.html . (The more official location
http://www.sgi.com/tech/stl/ropeimpl.html is missing a figure.)
All of these are descendents of the "ropes" in Xerox Cedar.
de.c is a very dumb text editor that illustrates the use of cords.
It maintains a list of file versions. Each version is simply a
cord representing the file contents. Nonetheless, standard
editing operations are efficient, even on very large files.
(Its 3 line "user manual" can be obtained by invoking it without
arguments. Note that ^R^N and ^R^P move the cursor by
almost a screen. It does not understand tabs, which will show
up as highlighred "I"s. Use the UNIX "expand" program first.)
To build the editor, type "make cord/de" in the gc directory.
This package assumes an ANSI C compiler such as gcc. It will
not compile with an old-style K&R compiler.
Note that CORD_printf iand friends use C functions with variable numbers
of arguments in non-standard-conforming ways. This code is known to
break on some platforms, notably PowerPC. It should be possible to
build the remainder of the library (everything but cordprnt.c) on
any platform that supports the collector.

141
libgc/doc/README.darwin Normal file
View File

@@ -0,0 +1,141 @@
6.5 update:
I disabled incremental GC on Darwin in this version, since I couldn't
get gctest to pass when the GC was built as a dynamic library. Building
with -DMPROTECT_VDB (and threads) on the command line should get you
back to the old state. - HB
./configure --enable-cplusplus results in a "make check" failure, probably
because the ::delete override ends up in a separate dl, and Darwin dynamic
loader semantics appear to be such that this is not really visible to the
main program, unlike on ELF systems. Someone who understands dynamic
loading needs to lookat this. For now, gc_cpp.o needs to be linked
statically, if needed. - HB
Darwin/MacOSX Support - December 16, 2003
=========================================
Important Usage Notes
=====================
GC_init() MUST be called before calling any other GC functions. This
is necessary to properly register segments in dynamic libraries. This
call is required even if you code does not use dynamic libraries as the
dyld code handles registering all data segments.
When your use of the garbage collector is confined to dylibs and you
cannot call GC_init() before your libraries' static initializers have
run and perhaps called GC_malloc(), create an initialization routine
for each library to call GC_init():
#include <gc/gc.h>
extern "C" void my_library_init() { GC_init(); }
Compile this code into a my_library_init.o, and link it into your
dylib. When you link the dylib, pass the -init argument with
_my_library_init (e.g. gcc -dynamiclib -o my_library.dylib a.o b.o c.o
my_library_init.o -init _my_library_init). This causes
my_library_init() to be called before any static initializers, and
will initialize the garbage collector properly.
Note: It doesn't hurt to call GC_init() more than once, so it's best,
if you have an application or set of libraries that all use the
garbage collector, to create an initialization routine for each of
them that calls GC_init(). Better safe than sorry.
The incremental collector is still a bit flaky on darwin. It seems to
work reliably with workarounds for a few possible bugs in place however
these workaround may not work correctly in all cases. There may also
be additional problems that I have not found.
Thread-local GC allocation will not work with threads that are not
created using the GC-provided override of pthread_create(). Threads
created without the GC-provided pthread_create() do not have the
necessary data structures in the GC to store this data.
Implementation Information
==========================
Darwin/MacOSX support is nearly complete. Thread support is reliable on
Darwin 6.x (MacOSX 10.2) and there have been reports of success on older
Darwin versions (MacOSX 10.1). Shared library support had also been
added and the gc can be run from a shared library. There is currently only
support for Darwin/PPC although adding x86 support should be trivial.
Thread support is implemented in terms of mach thread_suspend and
thread_resume calls. These provide a very clean interface to thread
suspension. This implementation doesn't rely on pthread_kill so the
code works on Darwin < 6.0 (MacOSX 10.1). All the code to stop and
start the world is located in darwin_stop_world.c.
Since not all uses of the GC enable clients to override pthread_create()
before threads have been created, the code for stopping the world has
been rewritten to look for threads using Mach kernel calls. Each
thread identified in this way is suspended and resumed as above. In
addition, since Mach kernel threads do not contain pointers to their
stacks, a stack-walking function has been written to find the stack
limits. Given an initial stack pointer (for the current thread, a
pointer to a stack-allocated local variable will do; for a non-active
thread, we grab the value of register 1 (on PowerPC)), it
will walk the PPC Mach-O-ABI compliant stack chain until it reaches the
top of the stack. This appears to work correctly for GCC-compiled C,
C++, Objective-C, and Objective-C++ code, as well as for Java
programs that use JNI. If you run code that does not follow the stack
layout or stack pointer conventions laid out in the PPC Mach-O ABI,
then this will likely crash the garbage collector.
The original incremental collector support unfortunatelly no longer works
on recent Darwin versions. It also relied on some undocumented kernel
structures. Mach, however, does have a very clean interface to exception
handing. The current implementation uses Mach's exception handling.
Much thanks goes to Andrew Stone, Dietmar Planitzer, Andrew Begel,
Jeff Sturm, and Jesse Rosenstock for all their work on the
Darwin/OS X port.
-Brian Alliet
brian@brianweb.net
Older Information (Most of this no longer applies to the current code)
======================================================================
While the GC should work on MacOS X Server, MacOS X and Darwin, I only tested
it on MacOS X Server.
I've added a PPC assembly version of GC_push_regs(), thus the setjmp() hack is
no longer necessary. Incremental collection is supported via mprotect/signal.
The current solution isn't really optimal because the signal handler must decode
the faulting PPC machine instruction in order to find the correct heap address.
Further, it must poke around in the register state which the kernel saved away
in some obscure register state structure before it calls the signal handler -
needless to say the layout of this structure is no where documented.
Threads and dynamic libraries are not yet supported (adding dynamic library
support via the low-level dyld API shouldn't be that hard).
The original MacOS X port was brought to you by Andrew Stone.
June, 1 2000
Dietmar Planitzer
dave.pl@ping.at
Note from Andrew Begel:
One more fix to enable gc.a to link successfully into a shared library for
MacOS X. You have to add -fno-common to the CFLAGS in the Makefile. MacOSX
disallows common symbols in anything that eventually finds its way into a
shared library. (I don't completely understand why, but -fno-common seems to
work and doesn't mess up the garbage collector's functionality).
Feb 26, 2003
Jeff Sturm and Jesse Rosenstock provided a patch that adds thread support.
GC_MACOSX_THREADS should be defined in the build and in clients. Real
dynamic library support is still missing, i.e. dynamic library data segments
are still not scanned. Code that stores pointers to the garbage collected
heap in statically allocated variables should not reside in a dynamic
library. This still doesn't appear to be 100% reliable.
Mar 10, 2003
Brian Alliet contributed dynamic library support for MacOSX. It could also
use more testing.

12
libgc/doc/README.dj Normal file
View File

@@ -0,0 +1,12 @@
[Original version supplied by Xiaokun Zhu <xiaokun@aero.gla.ac.uk>]
[This version came mostly from Gary Leavens. ]
Look first at Makefile.dj, and possibly change the definitions of
RM and MV if you don't have rm and mv installed.
Then use Makefile.dj to compile the garbage collector.
For example, you can do:
make -f Makefile.dj test
All the tests should work fine.

151
libgc/doc/README.environment Normal file
View File

@@ -0,0 +1,151 @@
The garbage collector looks at a number of environment variables which are
then used to affect its operation. These are examined only on Un*x-like
platforms and win32.
GC_INITIAL_HEAP_SIZE=<bytes> - Initial heap size in bytes. May speed up
process start-up.
GC_MAXIMUM_HEAP_SIZE=<bytes> - Maximum collected heap size.
GC_LOOP_ON_ABORT - Causes the collector abort routine to enter a tight loop.
This may make it easier to debug, such a process, especially
for multithreaded platforms that don't produce usable core
files, or if a core file would be too large. On some
platforms, this also causes SIGSEGV to be caught and
result in an infinite loop in a handler, allowing
similar debugging techniques.
GC_PRINT_STATS - Turn on as much logging as is easily feasible without
adding signifcant runtime overhead. Doesn't work if
the collector is built with SMALL_CONFIG. Overridden
by setting GC_quiet. On by default if the collector
was built without -DSILENT.
GC_DUMP_REGULARLY - Generate a GC debugging dump GC_dump() on startup
and during every collection. Very verbose. Useful
if you have a bug to report, but please include only the
last complete dump.
GC_BACKTRACES=<n> - Generate n random backtraces (for heap profiling) after
each GC. Collector must have been built with
KEEP_BACK_PTRS. This won't generate useful output unless
most objects in the heap were allocated through debug
allocators. This is intended to be only a statistical
sample; individual traces may be erroneous due to
concurrent heap mutation.
GC_PRINT_ADDRESS_MAP - Linux only. Dump /proc/self/maps, i.e. various address
maps for the process, to stderr on every GC. Useful for
mapping root addresses to source for deciphering leak
reports.
GC_NPROCS=<n> - Linux w/threads only. Explicitly sets the number of processors
that the GC should expect to use. Note that setting this to 1
when multiple processors are available will preserve
correctness, but may lead to really horrible performance,
since the lock implementation will immediately yield without
first spinning.
GC_MARKERS=<n> - Linux w/threads and parallel marker only. Set the number
of marker threads. This is normaly set to the number of
processors. It is safer to adjust GC_MARKERS than GC_NPROCS,
since GC_MARKERS has no impact on the lock implementation.
GC_NO_BLACKLIST_WARNING - Prevents the collector from issuing
warnings about allocations of very large blocks.
Deprecated. Use GC_LARGE_ALLOC_WARN_INTERVAL instead.
GC_LARGE_ALLOC_WARN_INTERVAL=<n> - Print every nth warning about very large
block allocations, starting with the nth one. Small values
of n are generally benign, in that a bounded number of
such warnings generally indicate at most a bounded leak.
For best results it should be set at 1 during testing.
Default is 5. Very large numbers effectively disable the
warning.
GC_IGNORE_GCJ_INFO - Ignore the type descriptors implicitly supplied by
GC_gcj_malloc and friends. This is useful for debugging
descriptor generation problems, and possibly for
temporarily working around such problems. It forces a
fully conservative scan of all heap objects except
those known to be pointerfree, and may thus have other
adverse effects.
GC_PRINT_BACK_HEIGHT - Print max length of chain through unreachable objects
ending in a reachable one. If this number remains
bounded, then the program is "GC robust". This ensures
that a fixed number of misidentified pointers can only
result in a bounded space leak. This currently only
works if debugging allocation is used throughout.
It increases GC space and time requirements appreciably.
This feature is still somewhat experimental, and requires
that the collector have been built with MAKE_BACK_GRAPH
defined. For details, see Boehm, "Bounding Space Usage
of Conservative Garbage Collectors", POPL 2001, or
http://lib.hpl.hp.com/techpubs/2001/HPL-2001-251.html .
GC_RETRY_SIGNALS, GC_NO_RETRY_SIGNALS - Try to compensate for lost
thread suspend signals in linux_threads.c. On by
default for GC_OSF1_THREADS, off otherwise. Note
that this does not work around a possible loss of
thread restart signals. This seems to be necessary for
some versions of Tru64. Since we've previously seen
similar issues on some other operating systems, it
was turned into a runtime flag to enable last-minute
work-arounds.
GC_IGNORE_FB[=<n>] - (Win32 only.) Try to avoid treating a mapped
frame buffer as part of the root set. Certain (higher end?)
graphics cards seems to result in the graphics memory mapped
into the user address space as writable memory.
Unfortunately, there seems to be no systematic way to
identify such memory. Setting the environment variable to n
causes the collector to ignore mappings longer than n MB.
The default value of n is currently 15. (This should cover
a 16 MB graphics card, since the mapping appears to be slightly
shorter than all of graphics memory. It will fail if a dll
writes pointers to collectable objects into a data segment
whose length is >= 15MB. Empirically that's rare, but
certainly possible.) WARNING: Security sensitive applications
should probably disable this feature by setting
GC_disallow_ignore_fb, or by building with -DNO_GETENV,
since small values could force collection of reachable
objects, which is conceivably a (difficult to exploit)
security hole. GC_IGNORE_FB values less than 3 MB
are never honored, eliminating this risk for most,
but not all, applications. This feature is likely to disappear
if/when we find a less disgusting "solution".
IN VERSION 6.4 AND LATER, THIS SHOULD BE UNNECESSARY.
The following turn on runtime flags that are also program settable. Checked
only during initialization. We expect that they will usually be set through
other means, but this may help with debugging and testing:
GC_ENABLE_INCREMENTAL - Turn on incremental collection at startup. Note that,
depending on platform and collector configuration, this
may involve write protecting pieces of the heap to
track modifications. These pieces may include pointerfree
objects or not. Although this is intended to be
transparent, it may cause unintended system call failures.
Use with caution.
GC_PAUSE_TIME_TARGET - Set the desired garbage collector pause time in msecs.
This only has an effect if incremental collection is
enabled. If a collection requires appreciably more time
than this, the client will be restarted, and the collector
will need to do additional work to compensate. The
special value "999999" indicates that pause time is
unlimited, and the incremental collector will behave
completely like a simple generational collector. If
the collector is configured for parallel marking, and
run on a multiprocessor, incremental collection should
only be used with unlimited pause time.
GC_FIND_LEAK - Turns on GC_find_leak and thus leak detection. Forces a
collection at program termination to detect leaks that would
otherwise occur after the last GC.
GC_ALL_INTERIOR_POINTERS - Turns on GC_all_interior_pointers and thus interior
pointer recognition.
GC_DONT_GC - Turns off garbage collection. Use cautiously.

81
libgc/doc/README.ews4800 Normal file
View File

@@ -0,0 +1,81 @@
GC on EWS4800
-------------
1. About EWS4800
EWS4800 is 32bit/64bit workstation.
Vender: NEC Corporation
OS: UX/4800 R9.* - R13.* (SystemV R4.2)
CPU: R4000, R4400, R10000 (MIPS)
2. Compiler
32bit:
Use ANSI C compiler.
CC = /usr/abiccs/bin/cc
64bit:
Use 64bit ANSI C compiler.
CC = /usr/ccs64/bin/cc
AR = /usr/ccs64/bin/ar
3. ELF file format
*** Caution: The following infomation is empirical. ***
32bit:
ELF file has an unique format. (See a.out(4) and end(3C).)
&_start
: text segment
&etext
DATASTART
: data segment (initialized)
&edata
DATASTART2
: data segment (uninitialized)
&end
Here, DATASTART and DATASTART2 are macros of GC, and are defined as
the following equations. (See include/private/gcconfig.h.)
The algorithm for DATASTART is similar with the function
GC_SysVGetDataStart() in os_dep.c.
DATASTART = ((&etext + 0x3ffff) & ~0x3ffff) + (&etext & 0xffff)
Dynamically linked:
DATASTART2 = (&_gp + 0x8000 + 0x3ffff) & ~0x3ffff
Statically linked:
DATASTART2 = &edata
GC has to check addresses both between DATASTART and &edata, and
between DATASTART2 and &end. If a program accesses between &etext
and DATASTART, or between &edata and DATASTART2, the segmentation
error occurs and the program stops.
If a program is statically linked, there is not a gap between
&edata and DATASTART2. The global symbol &_DYNAMIC_LINKING is used
for the detection.
64bit:
ELF file has a simple format. (See end(3C).)
_ftext
: text segment
_etext
_fdata = DATASTART
: data segment (initialized)
_edata
_fbss
: data segment (uninitialized)
_end = DATAEND
--
Hironori SAKAMOTO <hsaka@mth.biglobe.ne.jp>
When using the new "configure; make" build process, please
run configure with the --disable-shared option. "Make check" does not
yet pass with dynamic libraries. Ther reasons for that are not yet
understood. (HB, paraphrasing message from Hironori SAKAMOTO.)

18
libgc/doc/README.hp Normal file
View File

@@ -0,0 +1,18 @@
Dynamic loading support requires that executables be linked with -ldld.
The alternative is to build the collector without defining DYNAMIC_LOADING
in gcconfig.h and ensuring that all garbage collectable objects are
accessible without considering statically allocated variables in dynamic
libraries.
The collector should compile with either plain cc or cc -Ae. Cc -Aa
fails to define _HPUX_SOURCE and thus will not configure the collector
correctly.
Incremental collection support was reccently added, and should now work.
In spite of past claims, pthread support under HP/UX 11 should now work.
Define GC_HPUX_THREADS for the build. Incremental collection still does not
work in combination with it.
The stack finding code can be confused by putenv calls before collector
initialization. Call GC_malloc or GC_init before any putenv calls.

132
libgc/doc/README.linux Normal file
View File

@@ -0,0 +1,132 @@
See README.alpha for Linux on DEC AXP info.
This file applies mostly to Linux/Intel IA32. Ports to Linux on an M68K, IA64,
SPARC, MIPS, Alpha and PowerPC are also integrated. They should behave
similarly, except that the PowerPC port lacks incremental GC support, and
it is unknown to what extent the Linux threads code is functional.
See below for M68K specific notes.
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
of older versions of glibc and gdb.
The garbage collector uses SIGPWR and SIGXCPU if it is used with
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 or NPTL (which are included in libc6).
The collector relies on some implementation details of the LinuxThreads
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.
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.
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 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
In any case, _REENTRANT should be defined during compilation.
4) Dlopen() disables collection during its execution. (It can't run
concurrently with the collector, since the collector looks at its
data structures. It can't acquire the allocator lock, since arbitrary
user startup code may run as part of dlopen().) Under unusual
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.
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.)
M68K LINUX:
(From Richard Zidlicky)
The bad news is that it can crash every linux-m68k kernel on a 68040,
so an additional test is needed somewhere on startup. I have meanwhile
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
upon startup. If it fails (return !0) than mprotect can't be used
on that system.
/*
* test for bug that may crash 68040 based Linux
*/
#include <sys/mman.h>
#include <signal.h>
#include <unistd.h>
#include <stdio.h>
#include <stdlib.h>
char *membase;
int pagesize=4096;
int pageshift=12;
int x_taken=0;
int sighandler(int sig)
{
mprotect(membase,pagesize,PROT_READ|PROT_WRITE);
x_taken=1;
}
main()
{
long l;
signal(SIGSEGV,sighandler);
l=(long)mmap(NULL,pagesize,PROT_READ,MAP_PRIVATE | MAP_ANON,-1,0);
if (l==-1)
{
perror("mmap/malloc");
abort();
}
membase=(char*)l;
*(long*)(membase+sizeof(long))=123456789;
if (*(long*)(membase+sizeof(long)) != 123456789 )
{
fprintf(stderr,"writeback failed !\n");
exit(1);
}
if (!x_taken)
{
fprintf(stderr,"exception not taken !\n");
exit(1);
}
fprintf(stderr,"vmtest Ok\n");
exit(0);
}

94
libgc/doc/README.macros Normal file
View File

@@ -0,0 +1,94 @@
The collector uses a large amount of conditional compilation in order to
deal with platform dependencies. This violates a number of known coding
standards. On the other hand, it seems to be the only practical way to
support this many platforms without excessive code duplication.
A few guidelines have mostly been followed in order to keep this manageable:
1) #if and #ifdef directives are properly indented whenever easily possible.
All known C compilers allow whitespace between the "#" and the "if" to make
this possible. ANSI C also allows white space before the "#", though we
avoid that. It has the known disadvantages that it differs from the normal
GNU conventions, and that it makes patches larger than otherwise necessary.
In my opinion, it's still well worth it, for the same reason that we indent
ordinary "if" statements.
2) Whenever possible, tests are performed on the macros defined in gcconfig.h
instead of directly testing patform-specific predefined macros. This makes it
relatively easy to adapt to new compilers with a different set of predefined
macros. Currently these macros generally identify platforms instead of
features. In many cases, this is a mistake.
3) The code currently avoids #elif, eventhough that would make it more
readable. This was done since #elif would need to be understood by ALL
compilers used to build the collector, and that hasn't always been the case.
It makes sense to reconsider this decision at some point, since #elif has been
standardized at least since 1989.
Many of the tested configuration macros are at least somewhat defined in
either include/private/gcconfig.h or in Makefile.direct. Here is an attempt
at defining some of the remainder: (Thanks to Walter Bright for suggesting
this. This is a work in progress)
MACRO EXPLANATION
----- -----------
__DMC__ Always #define'd by the Digital Mars compiler. Expands
to the compiler version number in hex, i.e. 0x810 is
version 8.1b0
_ENABLE_ARRAYNEW
#define'd by the Digital Mars C++ compiler when
operator new[] and delete[] are separately
overloadable. Used in gc_cpp.h.
_MSC_VER Expands to the Visual C++ compiler version. Assumed to
not be defined for other compilers (at least if they behave
appreciably differently).
_DLL Defined by Visual C++ if dynamic libraries are being built
or used. Used to test whether __declspec(dllimport) or
__declspec(dllexport) needs to be added to declarations
to support the case in which the collector is in a dll.
GC_DLL User-settable macro that forces the effect of _DLL. Set
by gc.h if _DLL is defined and GC_NOT_DLL is undefined.
This is the macro that is tested internally to determine
whether the GC is in its own dynamic library. May need
to be set by clients before including gc.h. Note that
inside the GC implementation it indicates that the
collector is in its own dynamic library, should export
its symbols, etc. But in clients it indicates that the
GC resides in a different DLL, its entry points should
be referenced accordingly, and precautions may need to
be taken to properly deal with statically allocated
variables in the main program. Used only for MS Windows.
GC_NOT_DLL User-settable macro that overrides _DLL, e.g. if dynamic
libraries are used, but the collector is in a static library.
__STDC__ Assumed to be defined only by compilers that understand
prototypes and other C89 features. Its value is generally
not used, since we are fine with most nonconforming extensions.
SUNOS5SIGS Solaris-like signal handling. This is probably misnamed,
since it really doesn't guarantee much more than Posix.
Currently set only for Solaris2.X, HPUX, and DRSNX. Should
probably be set for some other platforms.
PCR Set if the collector is being built as part of the Xerox
Portable Common Runtime.
SRC_M3 Set if the collector is being built as a replacement of the
one in the DEC/Compaq SRC Modula-3 runtime. I suspect this
was last used around 1994, and no doubt broke a long time ago.
It's there primarily incase someone wants to port to a similar
system.
USE_COMPILER_TLS Assume the existence of __thread-style thread-local
storage. Set automatically for thread-local allocation with
the HP/UX vendor compiler. Usable with gcc on sufficiently
up-to-date ELF platforms.

Some files were not shown because too many files have changed in this diff Show More