Re: Bug#116823: Debian's g++-3.0 forgets to generate some code.
On Wed, 24 Oct 2001, Martin v. Loewis wrote:
> I'd say that the best solution would be to get rid of globals. This is
> actually very easy:
>
> If you have
>
> TYPE VAR = INITIALIZER;
>
> replace that with
>
> TYPE& getVAR(){
> static TYPE obj = INITIALIZER;
> return obj;
> }
>
> Then use getVAR() whereever you've used VAR before. For backwards
> compatibility, you can even do
>
> #define VAR (getVAR())
>
> In understand that modules don't share global objects (perhaps except
> for the module singleton), so removing global should be a local change
> inside each module only.
I don't like this `construct on first use' idiom at all, aesthetically. I
find it disgusting to use a function call for that and a preprocessor
symbol.
But maybe I'll do something else in the mid-term future. We've been using
this `construct on first use' idiom until recently in GiNaC for flyweights
and last week I finally got rid of them by setting them up similarly to
how libstdc++-v3 sets up cin, cout, etc (i.e. section 27.4.2.1.6). That
requires us to have a single controller module that explicitly knows about
the dependencies, but since there are only 43, as you have noticed, this
might be an option worth considering.
> > The best solution would be to teach the linker about it.
>
> The linker actually does know about constructor order. In g++, there
> is a guarantee that object files within the same executable or shared
> library are initialized from right to left, in the order in which the
> objects appear on the linker line.
Arguably, that order is too simplistic. It should analyze the
dependencies among the globals, see if they form a DAG and rearrange the
order so that the DAG is traversed correctly when the library/program
fires up.
> > The solution we are talking about here is just a rather
> > unconventional but beautiful one.
>
> Looking at the code in module.h, I'd question that there is anything
> beautiful about it.
No, the macros are obscene, as mentioned in the comment! :-)
But the way one can use them is quite nice, I'd say.
> > Rather than that or changing the module ordering macros and writing
> > autoconf scripts to see if the global dtors are making use of
> > cxa-atexit I guess I'll just switch on -fno-use-cxa-atexit in CLN
> > whenever GCC-3.x is used. Hope this'll work for a couple of
> > years...
>
> I very much doubt that. Somebody will notice that the _GLOBAL__
> symbols don't need unique names at all, since they are not global (in
> fact, static_initialization_and_destruction is already in gcc 2.95 a
> single function for both ctors and dtors, so it is questionable
> whether these "clever" macros really get the control flow right).
>
> Furthermore, the C++ ABI really specifies that the .init and .fini
> sections shouldn't be used for constructors and destructors. For
> constructors, .initarray should be used, to allow portable integration
> of constructors across different compilers. Destructor sections should
> not be used, instead, cxa_atexit won't be an option at some time in
> the future.
Aha. Thanks for that input!
Regards
-richy.
--
.''`. Richard B. Kreckel
: :' : <kreckel@debian.org>
`. `' <kreckel@ginac.de>
`- <http://www.ginac.de/~kreckel/>
Reply to: