This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Fix --with-build-config=bootstrap-ubsan bootstrap of lto-plugin (PR sanitizer/56781)
- From: Jakub Jelinek <jakub at redhat dot com>
- To: "H.J. Lu" <hjl dot tools at gmail dot com>
- Cc: Paolo Bonzini <bonzini at gnu dot org>, DJ Delorie <dj at redhat dot com>, Alexandre Oliva <aoliva at redhat dot com>, Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>, Richard Biener <rguenther at suse dot de>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 25 Mar 2014 20:57:21 +0100
- Subject: Re: [PATCH] Fix --with-build-config=bootstrap-ubsan bootstrap of lto-plugin (PR sanitizer/56781)
- Authentication-results: sourceware.org; auth=none
- References: <20140325192856 dot GW1817 at tucnak dot redhat dot com> <CAMe9rOo4BKhyrf=T7zDV9uPwm8KvD91K7wiRPtVojZo5YE+G4w at mail dot gmail dot com>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
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