gprof rejects egcs' global constructor calling functions

Hans-Bernhard Broeker broeker@physik.rwth-aachen.de
Thu May 25 04:54:00 GMT 2000


Hello, 

I had some email exchange lately with a user of the egcs-1.1.2 C++
compiler: he complained that something obviously must have gone
wrong with the profiling, since gprof insisted that main() was
being called twice, in an otherwise nice and clean program that
most definitely did not call main() a second time, from the 
inside.

After some discussion back and forth, I received a reproducible
test case from him, and indeed, something strange was happening:
one of the two alleged calls to main() was coming from 
__do_global_ctors_aux. Looking closer, that call actually wasn't
to main(), but to _GLOBAL_.I.main, a.k.a. the 'global constructors
keyed to main'.

All that with gprof-2.9.1 on an ix86-pc-linux-glibc2 box. 

Debugging gprof quickly showed the reason: in core_sym_class(),
in source file gprof/core.c, there's
a routine that checks every static symbol name to reject some
obvious non-function names. One of those tests rejects any
name with a '.' in it:

  /*
   * Can't zero-length name or funny characters in name, where
   * `funny' includes: `.' (.o file names) and `$' (Pascal labels).
   */
  if (!sym->name || sym->name[0] == '\0')
    {
      return 0;
    }

  for (name = sym->name; *name; ++name)
    {
      if (*name == '.' || *name == '$')
        {
          return 0;
        }
    }

Thus, gprof rejects the symbol _GLOBAL_.I.main
and attributes calls to it to the immediately preceding function
in the program. That happened to be main(), in this case.

This is clearly a bug, but I'm not fluent enough in the details of
the ELF specs to know if it's a bug in the compiler to have
chosen that name with '.'s in it, or if gprof is falsely rejecting
this symbol name.

For myself, I fixed it by adding a check before the one that
rejects '.': if the symbol name starts with '_GLOBAL_.I.' or
'_GLOBAL_.D.', it's accepted regardless of the '.'s .

If wanted, I can offer a patch for that (and some other minor
glitches in 'gprof -c' and 'gprof -l' support...)


-- 
Hans-Bernhard Broeker (broeker@physik.rwth-aachen.de)
Even if all the snow were burnt, ashes would remain.


More information about the Binutils mailing list