{
__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
OSDN Git Service
