STT_FILE symbols, GCC's -fdebug-prefix-map, and glibc

[Brooks Moses <bmoses at google dot com>]

I was updating the toolchain we use for a glibc build, and ran into a
convoluted little problem that I'd like some advice on.  I'm
crossposting to both binutils@ and libc-alpha@ because it's
fundamentally a binutils issue, but I expect it will need a glibc
workaround.

The relevant parts of the process are that we bootstrap a static-only
GCC-and-binutils toolchain, and then use that to build glibc.  We use
GCC's -fdebug-prefix-map option to remap the debug information in the
result to point at a directory where the debug information will
actually be installed, rather than to the build directory, and in a
postprocessing step we run "strings -a $file | grep $builddir" on all
of the resulting binary files to ensure that the debug information has
been correctly remapped.

The issue showed up when I updated the binutils version from 2.22 to a
2013-03-05 snapshot (it was what we had handy with the relevant local
patches).  Consider the following steps, starting with the
sysdeps/i386/start.S file from glibc 2.18:

$bootstrap/gcc start.S -c -fdebug-prefix-map=`pwd`=foo -g
-Wa,--noexecstack -o start.o
$bootstrap/gcc -nostdlib -nostartfiles -r -o crt1.o `pwd`/start.o

With the post-2.22 snapshot, this crt1.o file now gets a FILE symbol
in is .symtab section that contains the expanded `pwd`/start.o string.
 This symbol shows up in the "strings -a" output, and thus this fails
our hermeticity test.

(Note that, if I just use "start.o" instead of "`pwd`/start.o" on the
second command line, the FILE symbol only contains "start.o".
However, I can't do that in the actual glibc makefile, because make is
running in the source directory and start.o is in the build directory
which may be somewhere far away in the directory tree.)

Alan, I'm guessing this is a result of your patch here, and subsequent
refinements:
http://www.cygwin.com/ml/binutils/2012-06/msg00016.html

Any suggestions on the right way to address this?  Obviously we could
just change our test, but that seems like it would just be papering
over the problem.

Thanks!
- Brooks