This is the mail archive of the
mailing list for the GCC project.
Re: Global object constructors
On Wed, Nov 03, 1999 at 10:53:00PM +0100, Martin v. Loewis wrote:
> As a starting point, please share with us what platform you are
> working on. Assuming it is ELFish, here is how you could approach the
i686-pc-linux-gnu, based off of RH6.0, so yes, ELF.
> - set a break point on __do_global_ctors_aux. Unfortunately, in the
> - using nm, find the address of the copy of __do_global_ctors_aux
This works. Unfortunately in the abscence of debugging information,
the breakpoint is tinfo2.cc ;).
> - read the code of __do_global_ctors_aux to see what it does. Even
> better, compile it with -g :-(
I have read it (assuming this is it, from gcc/crtstuff.c):
static func_ptr __CTOR_END__;
for (p = __CTOR_END__ - 1; *p != (func_ptr) -1; p--)
Fair enough. I'm recompiling with -g so that it will be a bit more
comprehensible (editing gcc/Makefile, replace -g1 with -g).
Hm, this doesn't help. It thinks the line number is tinfo2.cc:300
> - Singe-step through that, with instruction steps (si). This will
> eventually get into
Eesh, I get to go through all of the dlopen() stuff because of a
shared library call early in the constructor list. And then printf
calls in dmalloc_verify()...
Hm, it looks like the culprit is in some nasty, nasty template
code. Specifically, I check the heap before and in the constructor of
a class derived from std::list, and it is fine before, but inside the
derived constructor the heap is bad. Either I'm picking up STL
weirdness (the std::list constructor does a bunch of STL allocates),
or I'm getting bad code generation from gcc in *my* template code in
between the std::list and derived constructor...
Thanks for your help,
Programmer "I wrote a song about dental floss,
Loki Entertainment Software but did anyone's teeth get cleaner?"
http://lokigames.com/~briareos/ - Frank Zappa, re: the PMRC