From 27f92b1609f366d1642bd8a4323cec8e317fe948 Mon Sep 17 00:00:00 2001 From: Olivier Hainque Date: Wed, 6 Jun 2007 12:36:28 +0200 Subject: [PATCH] initialize.c (__gnat_initialize for vxworks): Update documentation on the ZCX support... 2007-04-20 Olivier Hainque * 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 | 45 ++++++++++++++++++++++---------------------- 1 file changed, 23 insertions(+), 22 deletions(-) diff --git a/gcc/ada/initialize.c b/gcc/ada/initialize.c index 8da30896c4e..2fa0d026099 100644 --- a/gcc/ada/initialize.c +++ b/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 -- 2.30.2