On Tue, Mar 25, 2014 at 12:44:58PM -0700, H.J. Lu wrote:
> On Tue, Mar 25, 2014 at 12:28 PM, Jakub Jelinek <ja...@redhat.com> wrote:
> > lto-plugin is another problematic directory in asan/ubsan bootstraps.
> >
> > Unlike fixincludes, it is bootstrapped, and like fixincludes it is also
> > linked against host libiberty. The problem for lto-plugin is that the
> > -static-libubsan -fsanitize=undefined -B/some/path/to/libsanitizer/
> > -B/some/path/to/libsanitizer/ubsan/.libs/
> > switches are eaten by libtool, which throws them away on the floor.
> >
> > We apparently have libtool-ldflags which is used by other libraries
> > to filter some options so that libtool doesn't eat them, but even after
> > applying the lto-plugin/Makefile.am changes I got failures, because
> > while -fsanitize=undefined now made it through, the rest of the options
> > didn't. So, this patch also tweaks libtool-ldflags to handle some more
> > options.
> >
>
> lto-plugin is dlopened by ld. How does asan work in lto-plugin
> when ld isn't compiled with asan?
It works fine for ubsan, and your fix is not the right thing to do,
e.g. bootstrap-ubsan reveals some bugs in libiberty which would be otherwise
unnoticed if you always filter away the sanitizing options from libiberty.
So, I think my patch is the right thing to do for ubsan bootstraps, and for
asan bootstraps we'll need something different (build libiberty twice, or
build selected libiberty objects inside lto-plugin/ directory again, or
something similar). You do want the libiberty parts in cc1, cc1plus, xgcc
etc. instrumented.
Jakub
