initialize.c (__gnat_initialize for vxworks): Update documentation on the ZCX support...

2007-04-20  Olivier Hainque  <hainque@adacore.com>

	* initialize.c (__gnat_initialize for vxworks):  Update documentation
	on the ZCX support, using different sets of crtstuff objects than with
	GCC 3.4.

From-SVN: r125429

gcc/ada/initialize.c

@@ -115,37 +115,38 @@ __gnat_initialize (void *eh)
 {
   __gnat_init_float ();
 
-  /* On targets where we might be using the ZCX scheme, we need to register
-     the frame tables.
+  /* On targets where we use the ZCX scheme, we need to register the frame
+     tables at load/startup time.
 
      For applications loaded as a set of "modules", the crtstuff objects
-     linked in (crtbegin/end) are tailored to provide this service a-la C++
-     constructor fashion, typically triggered by the VxWorks loader.  This is
-     achieved by way of a special variable declaration in the crt object, the
-     name of which has been deduced by analyzing the output of the "munching"
-     step documented for C++.  The de-registration is handled symmetrically,
-     a-la C++ destructor fashion and typically triggered by the dynamic
-     unloader.  Note that since the tables shall be registered against a
-     common datastructure, libgcc should be one of the modules (vs being
-     partially linked against all the others at build time) and shall be
-     loaded first.
+     linked in (crtbegin.o/end.o) are tailored to provide this service
+     automatically, a-la C++ constructor fashion, triggered by the VxWorks
+     loader thanks to a special variable declaration in crtbegin.o (_ctors).
+
+     Automatic de-registration is handled symmetrically, a-la C++ destructor
+     fashion (with a _dtors variable also in crtbegin.o) triggered by the
+     dynamic unloader.
+
+     Note that since the tables shall be registered against a common
+     datastructure, libgcc should be one of the modules (vs being partially
+     linked against all the others at build time) and shall be loaded first.
 
      For applications linked with the kernel, the scheme above would lead to
-     duplicated symbols because the VxWorks kernel build "munches" by default.
-     To prevent those conflicts, we link against crtbegin/endS objects that
-     don't include the special variable and directly call the appropriate
-     function here. We'll never unload that, so there is no de-registration to
-     worry about.
+     duplicated symbols because the VxWorks kernel build "munches" by default,
+     so we link against crtbeginT.o instead of crtbegin.o, which doesn't
+     include the special variables. We know which set of crt objects is used
+     thanks to a boolean indicator present in both sets (__module_has_ctors),
+     and directly call the appropriate function here in the not-automatic
+     case. We'll never unload that, so there is no de-registration to worry
+     about.
 
      For whole applications loaded as a single module, we may use one scheme
      or the other, except for the mixed Ada/C++ case in which the first scheme
      would fail for the same reason as in the linked-with-kernel situation.
 
-     We can differentiate by looking at the __module_has_ctors value provided
-     by each class of crt objects. As of today, selecting the crt set with the
-     ctors/dtors capabilities (first scheme above) is triggered by adding
-     "-dynamic" to the gcc *link* command line options. Selecting the other
-     set of crt objects is achieved by "-static" instead.
+     Selecting the crt set with the ctors/dtors capabilities (first scheme
+     above) is triggered by adding "-dynamic" to the gcc *link* command line
+     options. Selecting the other set is achieved by using "-static" instead.
 
      This is a first approach, tightly synchronized with a number of GCC
      configuration and crtstuff changes. We need to ensure that those changes