Patchwork PATCH: Add --with-build-config=bootstrap-asan support

login
register
mail settings
Submitter H.J. Lu
Date Nov. 17, 2012, 11:54 p.m.
Message ID <20121117235441.GA25741@gmail.com>
Download mbox | patch
Permalink /patch/199890/
State New
Headers show

Comments

H.J. Lu - Nov. 17, 2012, 11:54 p.m.
Hi,

This patch adds --with-build-config=bootstrap-asan support.  OK to
install?

Thanks.


H.J.
---
2012-11-17  H.J. Lu  <hongjiu.lu@intel.com>

	* Makefile.def (target_modules): Add bootstrap=true for
	libsanitizer.
	* Makefile.tpl (LIBASAN_LIBS): New for gcc-bootstrap.  Defined
	if $(BUILD_CONFIG) contains bootstrap-asan.
	(POSTSTAGE1_CXX_EXPORT): Add $(LIBASAN_LIBS) to CXX.
	(POSTSTAGE1_HOST_EXPORTS): Add $(LIBASAN_LIBS) to CC.
	* configure.ac (bootstrap_target_libs): Add libsanitizer.
	* Makefile.in: Regenerated.
	* configure: Likewise.

config/

2012-11-17  H.J. Lu  <hongjiu.lu@intel.com>

	* bootstrap-asan.mk: New file.
Markus Trippelsdorf - Nov. 18, 2012, 3:47 a.m.
On 2012.11.17 at 15:54 -0800, H.J. Lu wrote:
> Hi,
> 
> This patch adds --with-build-config=bootstrap-asan support.  OK to
> install?

Wouldn't it make more sense to add an "--enable-checking=asan" option
instead?
Paolo Bonzini - Nov. 18, 2012, 3:28 p.m.
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.

Paolo

>  # This is the list of variables to export in the environment when
>  # configuring any subdirectory.  It must also be exported whenever
>  # recursing into a build directory in case that directory's Makefile
> @@ -242,6 +248,7 @@ POSTSTAGE1_CXX_EXPORT = \
>  	  -B$$r/$(HOST_SUBDIR)/prev-gcc/ -B$(build_tooldir)/bin/ -nostdinc++ \
>  	  -B$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/src/.libs \
>  	  -B$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs \
> +	  $(LIBASAN_LIBS) \
>  	  -I$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include/$(TARGET_SUBDIR) \
>  	  -I$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include \
>  	  -I$$s/libstdc++-v3/libsupc++ \
> @@ -256,6 +263,7 @@ POSTSTAGE1_HOST_EXPORTS = \
>  	$(HOST_EXPORTS) \
>  	CC="$(STAGE_CC_WRAPPER) $$r/$(HOST_SUBDIR)/prev-gcc/xgcc$(exeext) \
>  	  -B$$r/$(HOST_SUBDIR)/prev-gcc/ -B$(build_tooldir)/bin/ \
> +	  $(LIBASAN_LIBS) \
>  	  $(XGCC_FLAGS_FOR_TARGET) $$TFLAGS"; export CC; \
>  	CC_FOR_BUILD="$$CC"; export CC_FOR_BUILD; \
>  	$(POSTSTAGE1_CXX_EXPORT) \
H.J. Lu - Nov. 18, 2012, 3:56 p.m.
On Sun, Nov 18, 2012 at 7:28 AM, Paolo Bonzini <bonzini@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 works. I will post a new patch to include a workaround for

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55380

Thanks.
Hans-Peter Nilsson - Nov. 18, 2012, 3:59 p.m.
On Sun, 18 Nov 2012, H.J. Lu wrote:
> On Sun, Nov 18, 2012 at 7:28 AM, Paolo Bonzini <bonzini@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 works. I will post a new patch to include a workaround for
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55380
>
> Thanks.

Nice, but I agree with the other poster that this'd IMHO be
better as --enable-checking=asan (or actually,
--enable-checking=all,asan).

brgds, H-P
Paolo Bonzini - Nov. 18, 2012, 4:04 p.m.
Il 18/11/2012 16:59, Hans-Peter Nilsson ha scritto:
> On Sun, 18 Nov 2012, H.J. Lu wrote:
>> On Sun, Nov 18, 2012 at 7:28 AM, Paolo Bonzini <bonzini@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 works. I will post a new patch to include a workaround for
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55380
>>
>> Thanks.
> 
> Nice, but I agree with the other poster that this'd IMHO be
> better as --enable-checking=asan (or actually,
> --enable-checking=all,asan).

Yeah, that's a good thing to support too.  However, you still need a
toplevel build configuration to enable asan post-stage1.  Configuring
with --enable-checking=all,asan would require the bootstrap compiler to
support asan, too.

Paolo
H.J. Lu - Nov. 18, 2012, 4:04 p.m.
On Sun, Nov 18, 2012 at 7:59 AM, Hans-Peter Nilsson <hp@bitrange.com> wrote:
> On Sun, 18 Nov 2012, H.J. Lu wrote:
>> On Sun, Nov 18, 2012 at 7:28 AM, Paolo Bonzini <bonzini@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 works. I will post a new patch to include a workaround for
>>
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55380
>>
>> Thanks.
>
> Nice, but I agree with the other poster that this'd IMHO be
> better as --enable-checking=asan (or actually,
> --enable-checking=all,asan).
>

ASAN isn't a checking feature enabled in GCC source
without any compiler requirements.  It is a compiler
feature, similar to LTO. For example, you can't enable
ASAN in stage 1 since stage 1 compiler may not support
ASAN.  I believe  --with-build-config=bootstrap-asan
is the best fit.
Hans-Peter Nilsson - Nov. 19, 2012, 12:19 a.m.
On Sun, 18 Nov 2012, Paolo Bonzini wrote:
> Il 18/11/2012 16:59, Hans-Peter Nilsson ha scritto:
> > Nice, but I agree with the other poster that this'd IMHO be
> > better as --enable-checking=asan (or actually,
> > --enable-checking=all,asan).
>
> Yeah, that's a good thing to support too.  However, you still need a
> toplevel build configuration to enable asan post-stage1.  Configuring
> with --enable-checking=all,asan would require the bootstrap compiler to
> support asan, too.

We seem to be able to add various flags to compilations *after*
the first stage (that are not valid at the first stage, for the
bootstrapping/host compiler) so I still don't get why this
should be conceptually different.  But whatever.

brgds, H-P
H.J. Lu - Nov. 19, 2012, 4:35 a.m.
On Sun, Nov 18, 2012 at 7:28 AM, Paolo Bonzini <bonzini@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

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.

So basically we can only use -faddress-sanitizer in
the gcc directory, which isn't easy to do.

Also I have to mark libsanitizer as bootstrap otherwise
multilib libsanitizer will get -funconfigured-libstcd++-v3.

I checked my patches into hjl/asan git branch:

http://gcc.gnu.org/git/?p=gcc.git;a=shortlog;h=refs/heads/hjl/asan

I will submit them after running some tests.
Paolo Bonzini - Nov. 19, 2012, 8:01 a.m.
Il 19/11/2012 05:35, H.J. Lu ha scritto:
> On Sun, Nov 18, 2012 at 7:28 AM, Paolo Bonzini <bonzini@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.

> 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.

> So basically we can only use -faddress-sanitizer in
> the gcc directory, which isn't easy to do.

No, there's no need for that.

> Also I have to mark libsanitizer as bootstrap otherwise
> multilib libsanitizer will get -funconfigured-libstcd++-v3.

Yes, that part's okay.

Paolo
Konstantin Serebryany - Nov. 19, 2012, 8:18 a.m.
> 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.

Do you mean, does asan compilation cause some special preprocessor
symbol to be defined?
No, asan  compilation does not define any preprocessor symbol.
In clang, there are two ways to workaround asan-hostile code: one is a
function attribute and another is __has_feature macro
http://clang.llvm.org/docs/AddressSanitizer.html#has_feature
Both are clang-specific today, but both make sense in gcc as well.

--kcc
Martin Jambor - Nov. 19, 2012, 12:13 p.m.
Hi,

On Sat, Nov 17, 2012 at 03:54:41PM -0800, H.J. Lu wrote:
> Hi,
> 
> This patch adds --with-build-config=bootstrap-asan support.  OK to
> install?

I suppose this should be also described in gcc/doc/install.texi?

Thanks,

Martin


> 
> Thanks.
> 
> 
> H.J.
> ---
> 2012-11-17  H.J. Lu  <hongjiu.lu@intel.com>
> 
> 	* Makefile.def (target_modules): Add bootstrap=true for
> 	libsanitizer.
> 	* Makefile.tpl (LIBASAN_LIBS): New for gcc-bootstrap.  Defined
> 	if $(BUILD_CONFIG) contains bootstrap-asan.
> 	(POSTSTAGE1_CXX_EXPORT): Add $(LIBASAN_LIBS) to CXX.
> 	(POSTSTAGE1_HOST_EXPORTS): Add $(LIBASAN_LIBS) to CC.
> 	* configure.ac (bootstrap_target_libs): Add libsanitizer.
> 	* Makefile.in: Regenerated.
> 	* configure: Likewise.
> 
> config/
> 
> 2012-11-17  H.J. Lu  <hongjiu.lu@intel.com>
> 
> 	* bootstrap-asan.mk: New file.
> 
> diff --git a/Makefile.def b/Makefile.def
> index 1ea63ac..8d54ad2 100644
> --- a/Makefile.def
> +++ b/Makefile.def
> @@ -119,7 +119,7 @@ target_modules = { module= libstdc++-v3;
>  		   lib_path=src/.libs;
>  		   raw_cxx=true; };
>  target_modules = { module= libmudflap; lib_path=.libs; };
> -target_modules = { module= libsanitizer; lib_path=.libs; };
> +target_modules = { module= libsanitizer; bootstrap=true; lib_path=.libs; };
>  target_modules = { module= libssp; lib_path=.libs; };
>  target_modules = { module= newlib; };
>  target_modules = { module= libgcc; bootstrap=true; no_check=true; };
> diff --git a/Makefile.tpl b/Makefile.tpl
> index 146666a..e40e92b 100644
> --- a/Makefile.tpl
> +++ b/Makefile.tpl
> @@ -131,6 +131,12 @@ POSTSTAGE1_LDFLAGS = @poststage1_ldflags@
>  # Libraries to use for stage2 and later.
>  POSTSTAGE1_LIBS = @poststage1_libs@
>  
> +@if gcc-bootstrap
> +ifneq ($(filter bootstrap-asan,$(BUILD_CONFIG)),)
> +LIBASAN_LIBS=-B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/asan/.libs
> +endif
> +@endif gcc-bootstrap
> +
>  # This is the list of variables to export in the environment when
>  # configuring any subdirectory.  It must also be exported whenever
>  # recursing into a build directory in case that directory's Makefile
> @@ -242,6 +248,7 @@ POSTSTAGE1_CXX_EXPORT = \
>  	  -B$$r/$(HOST_SUBDIR)/prev-gcc/ -B$(build_tooldir)/bin/ -nostdinc++ \
>  	  -B$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/src/.libs \
>  	  -B$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs \
> +	  $(LIBASAN_LIBS) \
>  	  -I$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include/$(TARGET_SUBDIR) \
>  	  -I$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include \
>  	  -I$$s/libstdc++-v3/libsupc++ \
> @@ -256,6 +263,7 @@ POSTSTAGE1_HOST_EXPORTS = \
>  	$(HOST_EXPORTS) \
>  	CC="$(STAGE_CC_WRAPPER) $$r/$(HOST_SUBDIR)/prev-gcc/xgcc$(exeext) \
>  	  -B$$r/$(HOST_SUBDIR)/prev-gcc/ -B$(build_tooldir)/bin/ \
> +	  $(LIBASAN_LIBS) \
>  	  $(XGCC_FLAGS_FOR_TARGET) $$TFLAGS"; export CC; \
>  	CC_FOR_BUILD="$$CC"; export CC_FOR_BUILD; \
>  	$(POSTSTAGE1_CXX_EXPORT) \
> diff --git a/config/bootstrap-asan.mk b/config/bootstrap-asan.mk
> new file mode 100644
> index 0000000..cae203b
> --- /dev/null
> +++ b/config/bootstrap-asan.mk
> @@ -0,0 +1,5 @@
> +# This option enables -faddress-sanitizer for stage2 and stage3.
> +
> +STAGE2_CFLAGS += -faddress-sanitizer
> +STAGE3_CFLAGS += -faddress-sanitizer
> +POSTSTAGE1_LDFLAGS += -faddress-sanitizer -static-libasan
> diff --git a/configure.ac b/configure.ac
> index 24ea7e5..64e0387 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -2433,6 +2433,11 @@ if echo " ${target_configdirs} " | grep " libgomp " > /dev/null 2>&1 ; then
>    bootstrap_target_libs=${bootstrap_target_libs}target-libgomp,
>  fi
>  
> +# If we are building libsanitizer, bootstrap it.
> +if echo " ${target_configdirs} " | grep " libsanitizer " > /dev/null 2>&1 ; then
> +  bootstrap_target_libs=${bootstrap_target_libs}target-libsanitizer,
> +fi
> +
>  # Determine whether gdb needs tk/tcl or not.
>  # Use 'maybe' since enable_gdbtk might be true even if tk isn't available
>  # and in that case we want gdb to be built without tk.  Ugh!
H.J. Lu - Nov. 19, 2012, 3:06 p.m.
On Mon, Nov 19, 2012 at 12:01 AM, Paolo Bonzini <bonzini@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 <bonzini@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.


>> 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 basically we can only use -faddress-sanitizer in
>> the gcc directory, which isn't easy to do.
>
> No, there's no need for that.

I'd like to support separate linker.
Paolo Bonzini - Nov. 19, 2012, 8:34 p.m.
On Mon, Nov 19, 2012 at 4:06 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
> On Mon, Nov 19, 2012 at 12:01 AM, Paolo Bonzini <bonzini@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 <bonzini@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
H.J. Lu - Nov. 19, 2012, 9 p.m.
On Mon, Nov 19, 2012 at 12:34 PM, Paolo Bonzini <bonzini@gnu.org> wrote:
> On Mon, Nov 19, 2012 at 4:06 PM, H.J. Lu <hjl.tools@gmail.com> wrote:
>> On Mon, Nov 19, 2012 at 12:01 AM, Paolo Bonzini <bonzini@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 <bonzini@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.

I opened:

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55397

>>>> 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.

I will give it a try.

Patch

diff --git a/Makefile.def b/Makefile.def
index 1ea63ac..8d54ad2 100644
--- a/Makefile.def
+++ b/Makefile.def
@@ -119,7 +119,7 @@  target_modules = { module= libstdc++-v3;
 		   lib_path=src/.libs;
 		   raw_cxx=true; };
 target_modules = { module= libmudflap; lib_path=.libs; };
-target_modules = { module= libsanitizer; lib_path=.libs; };
+target_modules = { module= libsanitizer; bootstrap=true; lib_path=.libs; };
 target_modules = { module= libssp; lib_path=.libs; };
 target_modules = { module= newlib; };
 target_modules = { module= libgcc; bootstrap=true; no_check=true; };
diff --git a/Makefile.tpl b/Makefile.tpl
index 146666a..e40e92b 100644
--- a/Makefile.tpl
+++ b/Makefile.tpl
@@ -131,6 +131,12 @@  POSTSTAGE1_LDFLAGS = @poststage1_ldflags@
 # Libraries to use for stage2 and later.
 POSTSTAGE1_LIBS = @poststage1_libs@
 
+@if gcc-bootstrap
+ifneq ($(filter bootstrap-asan,$(BUILD_CONFIG)),)
+LIBASAN_LIBS=-B$$r/prev-$(TARGET_SUBDIR)/libsanitizer/asan/.libs
+endif
+@endif gcc-bootstrap
+
 # This is the list of variables to export in the environment when
 # configuring any subdirectory.  It must also be exported whenever
 # recursing into a build directory in case that directory's Makefile
@@ -242,6 +248,7 @@  POSTSTAGE1_CXX_EXPORT = \
 	  -B$$r/$(HOST_SUBDIR)/prev-gcc/ -B$(build_tooldir)/bin/ -nostdinc++ \
 	  -B$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/src/.libs \
 	  -B$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/libsupc++/.libs \
+	  $(LIBASAN_LIBS) \
 	  -I$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include/$(TARGET_SUBDIR) \
 	  -I$$r/prev-$(TARGET_SUBDIR)/libstdc++-v3/include \
 	  -I$$s/libstdc++-v3/libsupc++ \
@@ -256,6 +263,7 @@  POSTSTAGE1_HOST_EXPORTS = \
 	$(HOST_EXPORTS) \
 	CC="$(STAGE_CC_WRAPPER) $$r/$(HOST_SUBDIR)/prev-gcc/xgcc$(exeext) \
 	  -B$$r/$(HOST_SUBDIR)/prev-gcc/ -B$(build_tooldir)/bin/ \
+	  $(LIBASAN_LIBS) \
 	  $(XGCC_FLAGS_FOR_TARGET) $$TFLAGS"; export CC; \
 	CC_FOR_BUILD="$$CC"; export CC_FOR_BUILD; \
 	$(POSTSTAGE1_CXX_EXPORT) \
diff --git a/config/bootstrap-asan.mk b/config/bootstrap-asan.mk
new file mode 100644
index 0000000..cae203b
--- /dev/null
+++ b/config/bootstrap-asan.mk
@@ -0,0 +1,5 @@ 
+# This option enables -faddress-sanitizer for stage2 and stage3.
+
+STAGE2_CFLAGS += -faddress-sanitizer
+STAGE3_CFLAGS += -faddress-sanitizer
+POSTSTAGE1_LDFLAGS += -faddress-sanitizer -static-libasan
diff --git a/configure.ac b/configure.ac
index 24ea7e5..64e0387 100644
--- a/configure.ac
+++ b/configure.ac
@@ -2433,6 +2433,11 @@  if echo " ${target_configdirs} " | grep " libgomp " > /dev/null 2>&1 ; then
   bootstrap_target_libs=${bootstrap_target_libs}target-libgomp,
 fi
 
+# If we are building libsanitizer, bootstrap it.
+if echo " ${target_configdirs} " | grep " libsanitizer " > /dev/null 2>&1 ; then
+  bootstrap_target_libs=${bootstrap_target_libs}target-libsanitizer,
+fi
+
 # Determine whether gdb needs tk/tcl or not.
 # Use 'maybe' since enable_gdbtk might be true even if tk isn't available
 # and in that case we want gdb to be built without tk.  Ugh!