aboutsummaryrefslogtreecommitdiffstats
path: root/gc/doc/README.Mac
diff options
context:
space:
mode:
authorFumitoshi UKAI <ukai@debian.or.jp>2003-03-09 19:43:05 +0000
committerFumitoshi UKAI <ukai@debian.or.jp>2003-03-09 19:43:05 +0000
commit1dff73dfd6accb9bae971dd0f1ce15a182b0f75b (patch)
tree90442e8c55bb3e5d8aade44a20152d2d8e297608 /gc/doc/README.Mac
parentautoconficate (diff)
downloadw3m-1dff73dfd6accb9bae971dd0f1ce15a182b0f75b.tar.gz
w3m-1dff73dfd6accb9bae971dd0f1ce15a182b0f75b.zip
remove gc
Diffstat (limited to '')
-rw-r--r--gc/doc/README.Mac385
-rw-r--r--gc/doc/README.MacOSX27
2 files changed, 0 insertions, 412 deletions
diff --git a/gc/doc/README.Mac b/gc/doc/README.Mac
deleted file mode 100644
index 04f4682..0000000
--- a/gc/doc/README.Mac
+++ /dev/null
@@ -1,385 +0,0 @@
-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önvä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.¹ (Symantec C++/THINK C), mw/gctest.68K.¹, or mw/gctest.PPC.¹. 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.¹ and
-gclib-2.¹. 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.¹/gc.PPC.¹ 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.¹ and gclib-2.¹
-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.¹ 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
diff --git a/gc/doc/README.MacOSX b/gc/doc/README.MacOSX
deleted file mode 100644
index 2abf0b4..0000000
--- a/gc/doc/README.MacOSX
+++ /dev/null
@@ -1,27 +0,0 @@
-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).