On Mon, Nov 19, 2012 at 4:06 PM, H.J. Lu <hjl.to...@gmail.com> wrote: > On Mon, Nov 19, 2012 at 12:01 AM, Paolo Bonzini <bonz...@gnu.org> wrote: >> Il 19/11/2012 05:35, H.J. Lu ha scritto: >>> On Sun, Nov 18, 2012 at 7:28 AM, Paolo Bonzini <bonz...@gnu.org> wrote: >>>> Il 18/11/2012 00:54, H.J. Lu ha scritto: >>>>> +@if gcc-bootstrap >>>>> +ifneq ($(filter bootstrap-asan,$(BUILD_CONFIG)),) >>>>> +LIBASAN_LIBS=-B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/asan/.libs >>>>> +endif >>>>> +@endif gcc-bootstrap >>>> >>>> Do you need this to be here? POSTSTAGE1_*_EXPORT is only used when >>>> bootstrapping, and they are defined with "=" so the definition could be >>>> placed (or so it seems at first look) in bootstrap-asan.mk. >>>> >>> >>> It turns out to be quite tricky: >>> >>> 1. We can't use -faddress-sanitizer in libcpp due to >>> >>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55380 >> >> Does -faddress-sanitizer add a CPP symbol that lets you work around it? >> If not, it's a bug. If so, please make libcpp revert to the dump >> algorithm if said symbol is defined. > > No, it doesn't define a CPP symbol.
Then we have to fix this first. >>> 2. We can't use -faddress-sanitizer in libiberty since >>> it will make all host binaries depend on libasan. >>> 3. We can't use -faddress-sanitizer in lto-plugin >>> since it will make linker depends on libasan. >> >> These are features, not bugs. You asked for that explicitly. In fact, >> I think that using bootstrap-asan in a combined tree should make all >> host binaries use asan. > > That is true. But we have to support separate ld. My patch > will delegate this decision to each tool directory. So if a plugin uses asan, it cannot be linked with a program that doesn't use it? Is this documented anywhere? I suppose however that a plugin compiled without asan can be linked to a program that uses it. So, if asan-enabled lto-plugin doesn't work together with normal ld, the solution is to remove -faddress-sanitizer from the flags unless you are in a combined tree. Paolo