From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30672 invoked by alias); 10 Apr 2014 18:42:20 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 30661 invoked by uid 89); 10 Apr 2014 18:42:20 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.0 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-HELO: mx01.qsc.de Received: from mx01.qsc.de (HELO mx01.qsc.de) (213.148.129.14) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-SHA encrypted) ESMTPS; Thu, 10 Apr 2014 18:42:18 +0000 Received: from tux.net-b.de (port-92-194-7-91.dynamic.qsc.de [92.194.7.91]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx01.qsc.de (Postfix) with ESMTPSA id 772783CEE2; Thu, 10 Apr 2014 20:42:15 +0200 (CEST) Message-ID: <5346E607.3080806@net-b.de> Date: Thu, 10 Apr 2014 18:42:00 -0000 From: Tobias Burnus User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.3.0 MIME-Version: 1.0 To: DJ Delorie , Jakub Jelinek CC: bonzini@gnu.org, aoliva@redhat.com, Ralf.Wildenhues@gmx.de, rguenther@suse.de, gcc-patches@gcc.gnu.org Subject: Re: Patch ping References: <20140409130721.GK1817@tucnak.redhat.com> <201404092229.s39MTmXp015920@greed.delorie.com> <20140410055906.GP1817@tucnak.redhat.com> <201404101601.s3AG1VSv012678@greed.delorie.com> In-Reply-To: <201404101601.s3AG1VSv012678@greed.delorie.com> Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2014-04/txt/msg00520.txt.bz2 DJ Delorie wrote: >> >This is for the host libiberty only, and only when gcc is configured >> >a certain way. The intent is to have libiberty that is going to be >> >linked into all the build and host tools instrumented, so that we >> >actually catch bugs in libiberty or bugs in host/build tools calling >> >libiberty functions as much as possible, but for the lto-plugin, >> >which is dlopened by the linker which we don't have a control on, we >> >need host libiberty without the address sanitization because >> >otherwise it would only work properly if the linker itself has been >> >address sanitized. > > So, if libiberty isn't built with sanitization, it would still*work* > but not be instrumented? That's my understanding. However, currently, without the patch the sanitizer is also used with the LTO plugin, which breaks the build with --with-build-config=bootstrap-ubsan,bootstrap-asan. Always building libiberty without UBSAN/ASAN even when the bootstrap-asan/ubsan option has been used, would be an option. However, if one also sanitizes libiberty, one has the chance to find bugs also in that library. Tobias PS: I found the out-of-bounds checking of ASAN and the integer overflow checks of UBSAN very helpful for the program I use at work.