[PATCH] Driver: implement --runtime-sysroot option.

[Peter Collingbourne]

On Fri, May 24, 2013 at 09:39:12AM -0400, Rafael Espíndola wrote:
> > Why not use -Wl,--dynamic-linker for this?  Well, one of the goals of
> > the sanitizer tools is ease of use.  It would not be user friendly to
> > require the user to supply the correct path to the dynamic loader
> > (which can vary depending on the platform) in order to enable
> > full-process compile-time instrumentation.  One could also consider
> > infrastructure which would cause -fsanitize=* options to imply an
> > appropriate runtime sysroot, for which the ability to specify the
> > runtime sysroot would be an important prerequisite.
> 
> Having instrumented versions of libc would be  awesome!
> 
> I guess the name of the libraries itself can be backed in to
> -fsanitize=*. So for example the driver would pass -lasan-c to the
> linker for example.

I would prefer not to do this, as I think it would be too disruptive
for existing build systems.   Ideally I'd like to be able to add
a few extra flags to $CC/$CXX (or the build system's equivalent)
and have the sanitizer (mostly) just work.  Adding a prefix won't
achieve this, as library file names would change requiring changes
to the build system.  On the other hand, I think a separate sysroot
would allow us to achieve this relatively easily.

> For the linker search path, the existing logic
> should be sufficient. The issue is how should we search for the
> dynamic linker. Some notes
> 
> * We should not assume it is not in a system directory. Now that some
> BSD use clang as their system compiler they might be interested in
> having instrumented libc's available.

I agree, but on the other hand we should not assume it is in a system
directory.  I don't think we should try to prematurely make design
decisions for the BSD folks.

> * Can we just search a path relative to the driver install location in
> addition to system directories? This would be similar to how we look
> for libstdr++ for example.

I would prefer not to depend on path searching for a runtime component
such as the dynamic loader.  (For one thing, we may be cross compiling
so it may not make sense to search the path.)

> If those don't work, I think my only remaining objection to this patch
> is the option name sounds a bit too generic. What about dyld-path or
> even sanitazer-libc-path?

I chose that name because the runtime sysroot could in principle affect
things other than the dynamic loader path, although I admittedly
can't think of a good example of something else it ought to affect.
--dyld-prefix sounds good to me since it's evident that it isn't the
entire path to the loader.

Thanks,
-- 
Peter