PATCH: file unique name

[Mark Mitchell]

> get_file_function_name produces a name unique across all object files.
> Most times it can do this by using an external symbol discovered in the
> source file, but it falls back on a different scheme when no such name
> is found. Because of bootstrap comparisons, this unique name must be the
> same name on recompilation (we can't just make up a random number). It
> is generated from the source file name, plus the inode of the input
> file. That inode is not stable, and changes for source files created
> during the bootstrap. (This doesn't bite us at the moment, but does on
> the gcov reworking.)

A random number would really be better, but I understand the bootstrap
issue.

Any other scheme is more likely to yield inadvertant collisisons than
long random numbers.

> Using the inode for uniqueness is no better than
> using the full pathname of the file. We can approximate the latter using
> the current directory pathname, and the input filename, which is what this
> patch does.

I agree that this idea is more intuitive than the UNIX-specific notion
of inode.

This will change the set of external symbols present in some files.  In
theory, the symbols that change are not ones that are ever referenced
from elsewhere.  It is, I suppose, possible, that someone has figured out
these values and is "dlopen"ing the symbols.  I think these symbols might
also show up as typeid().name in something like:

  namespace {
    struct S { virtual void f(); }

    ... typeid(S).name() ...
  }

The point is that this patch might be considered an ABI change.  I don't
really think that is a sensible characterization -- recompiling the files
on another machine would already have caused a change -- but let's get
Jason's input.  If he's happy, the patch is approved for basic-improvements.

-- 
Mark Mitchell                mark@codesourcery.com
CodeSourcery, LLC            http://www.codesourcery.com