Bug#116823: Debian's g++-3.0 forgets to generate some code.
On Wed, Oct 24, 2001 at 05:59:24PM +0200, Richard B. Kreckel wrote:
> On Wed, 24 Oct 2001, Daniel Jacobowitz wrote:
> [...]
> > > Could you please provide a pointer or two to code samples or things that
> > > might be helpful implementing it the Right Way, since I intend to try and
> > > fix it? (Dunno if I'm old enough for this, though.)
> > >
> > > Thanks a lot for all the input, anyways.
> >
> > The basic trick is to create a section containing pointers to all
> > functions you want called. The code to do it is in crtstuff.c in the
> > GCC source, but it's a bit on the nasty side. Then you put a symbol
> > __FOO_BEGIN__ in an object file _at the beginning of your link command_
> > in that same section, and __FOO_END__ in an object file at the end.
>
> Gasp. I am still trying hard to understand what's going on in
> crtstuff.c...
>
> > I don't understand at all why CLN is jumping through these hoops. It
> > looks like it could just create global objects, and piggyback on GCC's
> > constructor mechanism. What on earth is it trying to accomplish?
>
> To get the calling order right. CLN consists of >800 source-code modules
> and uses a bridge pattern to abstract the actual implementation away from
> the interface.
>
> The code I submitted was expanded from a macro called CL_PROVIDE(foo).
> This is put as a marker into the source file where the static object we
> want to have initialized is sitting in. Then, CL_REQUIRE(foo) is put into
> the header file where that object is declared extern.
>
> This comment is lifted from file ${prefix}/include/cln/modules.h:
>
> // The order of initialization of different compilation units is not
> // specified in C++. AIX 4 has a linker which apparently does order
> // the modules according to dependencies, so that low-level modules
> // will be initialized earlier than the high-level modules which depend
> // on them. I have a patch for GNU ld that does the same thing.
> //
> // But for now, I take a half-automatic approach to the correct module
> // ordering problem: PROVIDE/REQUIRE, as in Common Lisp.
> //
> // CL_PROVIDE(module) must be the first code-generating entity in a module.
> // Inline function definitions can precede it, but global variable/function/
> // class definitions may not precede it.
> // Afterwards, any number of CL_REQUIRE(othermodule) is allowed.
> // At the end of the module, there must be a corresponding
> // CL_PROVIDE_END(module). (Sorry for this, it's really needed.)
> //
> // These macros work only with g++, and only in optimizing mode. But who
> // wants to use CLN with other C++ compilers anyway...
<sigh> If you're order-sensitive, you've got a problem. I suggest
fiddling with link order and normal constructors; it should behave
roughly as expected - objects first on link line link first.
Other than that there's not much you can do.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
Reply to: