Import boehm-gc snapshot, taken fromboehm

https://github.com/ivmai/bdwgc 9178e2b8f10eab0ac54c504c85022d0ea8ded36b


git-svn-id: https://gcc.gnu.org/svn/gcc/branches/boehm@194030 138bc75d-0d04-0410-961f-82ee72b054a4

1 files changed, 23 insertions, 45 deletions

diff --git a/boehm-gc/doc/README.Mac b/boehm-gc/doc/README.Mac
index 04f468251a1..c1bb132f460 100644
--- a/boehm-gc/doc/README.Mac
+++ b/boehm-gc/doc/README.Mac
@@ -1,3 +1,8 @@
+The contents of this file are old and pertain to pre-MacOSX versions.
+You probably really wanted README.darwin.
+
+---------------------------------------------
+
 Patrick Beard's Notes for building GC v4.12 with CodeWarrior Pro 2:
 ----------------------------------------------------------------------------
 The current build environment for the collector is CodeWarrior Pro 2.
@@ -6,8 +11,8 @@ 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.
+Configuring the collector is still done by editing the file
+:extra:Mac_files:MacOS_config.h.
 
 Lars Farm's suggestions on building the collector:
 ----------------------------------------------------------------------------
@@ -34,12 +39,6 @@ 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
@@ -58,14 +57,12 @@ As for target settings the major obstacles may be:
 - 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:
-=================
+== 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...
 
@@ -157,19 +154,13 @@ of every source file. I used these:
 #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
@@ -232,8 +223,7 @@ Files to  build the GC libraries:
                -- throw std::bad_alloc when out of memory
                -- gc_cpp.cc works just fine too
 
-2) Test that the library works with 'test.c'.
-=============================================
+== 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.
@@ -251,10 +241,10 @@ prefix:
 #include <ansi_prefix.mac.h>
 #undef NDEBUG
 
-#define ALL_INTERIOR_POINTERS	/* for GC_priv.h */
+#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'.
+== 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.
@@ -283,8 +273,8 @@ 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
-============
+== 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
@@ -293,17 +283,9 @@ 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).
+== Source Changes (GC 4.12a2) ==
 
+Very few. Just one tiny in the GC, not strictly needed.
 - test_cpp.cc
   made the first lines of main() look like this:
   ------------
@@ -330,7 +312,6 @@ Very few. Just one tiny in the GC, not strictly needed.
    It worked for me, hope it works for you.
 
    Lars Farm
-   18 July 1997
 ----------------------------------------------------------------------------
 
 
@@ -345,41 +326,38 @@ 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
+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 
+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
+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
+For Metrowerks C/C++ 4.5 you build gc.68K/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.¹
+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.
+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