[PATCH] Fix --with-build-config=bootstrap-ubsan bootstrap of lto-plugin (PR sanitizer/56781)

Jakub Jelinek jakub@redhat.com
Tue Mar 25 20:11:00 GMT 2014


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 <jakub@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



More information about the Gcc-patches mailing list