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 _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
