diff options
Diffstat (limited to 'gcc/ada/init.c')
| -rw-r--r-- | gcc/ada/init.c | 45 |
1 files changed, 26 insertions, 19 deletions
diff --git a/gcc/ada/init.c b/gcc/ada/init.c index 9d79b6c3c0e..9fe4aa13239 100644 --- a/gcc/ada/init.c +++ b/gcc/ada/init.c @@ -1812,27 +1812,34 @@ __gnat_initialize (void) /* On targets where we might be using the ZCX scheme, we need to register the frame tables. - For application "modules", the crtstuff objects linked in (crtbegin/endS) - are tailored to provide this service a-la C++ constructor fashion, - typically triggered by the dynamic 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 call is handled symetrically, a-la C++ - destructor fashion and typically triggered by the dynamic unloader. With - this scheme, a mixed Ada/C++ application has to be linked and loaded as - separate modules for each language, which is not unreasonable anyway. - - For applications statically linked with the kernel, the module scheme - above would lead to duplicated symbols because the VxWorks kernel build - "munches" by default. To prevent those conflicts, we link against - crtbegin/end 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. + For applications loaded as a set of "modules", the crtstuff objects + linked in (crtbegin/endS) are tailored to provide this service a-la C++ + static 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 call is handled + symetrically, 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 beeing + 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/end 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. + + 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 intended - for applications to be statically linked with the kernel is triggered by - adding "-static" to the gcc *link* command line options. + by each class of crt objects. As of today, selecting the crt set with the + static ctors/dtors capabilities (first scheme above) is triggered by + adding "-static" to the gcc *link* command line options. Without this, + the other set of crt objects is fetched. This is a first approach, tightly synchronized with a number of GCC configuration and crtstuff changes. We need to ensure that those changes |