Re: gprof rejects egcs' global constructor calling functions

[Hans-Bernhard Broeker <broeker at physik dot rwth-aachen dot de>]

On 25 May 2000, Ian Lance Taylor wrote:

> local_label, but it may want to do some additional tests.  The test
> for a '.' is a.out specific, but it doesn't really care about a '.'.
> It is trying to catch the `foo.o' N_SO symbols which appear in the
> a.out symbol table.  Maybe gprof should look for symbols ending in
> `.o'.

I.e. a better sequence of tests would be (in pseudo-code) like the
following?

	if (name is nonexistant (NULL or "")
            || bfd_is_local_label())
	    || (is a *.o filename symbol)
	    || (is a __gnu_compiled or __gcc2_compiled symbol)
           )
	   return 0;

	return 't'

For comparison, here's the patch I'm currently using. The first hunk is
inserted before the check against names containing a '.' or '$',
as it would never be reached, otherwise. The second adds the
'gcc2_compiled' symbol name.

--- binutils-2.9.1/gprof/core.c.orig    Fri May  1 17:49:42 1998
+++ binutils-2.9.1/gprof/core.c Wed May 24 23:06:05 2000
@@ -316,6 +316,16 @@
       return 0;
     }
 
+  /* HBB 20000524: We *do* want to keep symbols with '.' in their names,
+   * for the sake of C++ global constructors! So check for them before
+   * all symbols with a dot inside are dismissed: */
+  if (   !strncmp(sym->name, "_GLOBAL_.D.", 11)
+      || !strncmp(sym->name, "_GLOBAL_.I.", 11)
+     )
+    {
+      return 't';
+    }
+  
   for (name = sym->name; *name; ++name)
     {
       if (*name == '.' || *name == '$')
@@ -340,7 +350,10 @@
    * the real function.  (dj@ctron)
    */
       || !strncmp (sym->name, "__gnu_compiled", 14)
-      || !strncmp (sym->name, "___gnu_compiled", 15))
+      || !strncmp (sym->name, "___gnu_compiled", 15)
+  /* HBB 20000524: same for newer symbols 'gcc2_compiled': */
+      || !strncmp (sym->name, "__gcc2_compiled", 15)
+      || !strncmp (sym->name, "gcc2_compiled", 13))
     {

> No, __gnu_compiled is not a local label in the sense of
> bfd_is_local_label.  We may want a different central function for
> these.

That's what I thought, too. Should I try and invent one? I'm not sure my
coding skills are up to that task. 

Another question: should I send my above patches as a quick-fix to the
people who had the original problem (the Linux staff at the European
center for high-energy physicsr, CERN), or would it be advisable to wait
for a 'better' fix?

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