[rb-general] SOURCE_PREFIX_MAP format specification proposals

[John Gilmore]

I'm a bit confused by the SOURCE_PREFIX_MAP discussion.  Let me argue
a moment for simplicity rather than complexity.

It sounds like we're hoping to use it to map a bunch of path prefixes
so that the altered ones get embedded into binaries.  What's the
problem with fixing GCC to just remove those embedded path prefixes
from the binaries?  In every case?  Not based on some super magic
environment variable nor some special build option.  Just get rid of
them, full stop.

(I used to maintain GDB, and I also built the first reproducible
cross-GCC builds back in the 1990s.  Back then, to make cross-builds
produce identical binaries, we chose to eliminate a bunch of
irreproducible things that the compiler and assembler and binutils
were doing.  For example, we set the timestamps in the COFF object
file format to zeroes, rather than try to fake them.  Nobody was using
them anyway!)

If GDB on a binary that you compiled locally can't immediately access
the source code files via their embedded path value, it isn't a big
deal; the programmer who's running GDB will know where the sources
are, and GDB has a command for telling it what directories to look in
for the source files.

We already know that GDB on a binary that you installed from a build
farm or an OS distribution CD is not going to know where the sources
are locally available.  (Just getting 'debug symbols' packages is a
major pain and is very poorly integrated.  Did I say very very very
poorly integrated?)  So why do we need to store even a "mapped" path
pointing to source files?

The only other path I recall that 'needs' embedding in binaries is the
shared library path specified in -L options.  In that case it's a
path in the ultimate target system of the binaries (e.g. /usr/lib),
so it should not depend on the build paths.

	John