From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15980 invoked by alias); 28 Oct 2014 09:06: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 15966 invoked by uid 89); 28 Oct 2014 09:06:19 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES256-GCM-SHA384 encrypted) ESMTPS; Tue, 28 Oct 2014 09:06:18 +0000 Received: from int-mx09.intmail.prod.int.phx2.redhat.com (int-mx09.intmail.prod.int.phx2.redhat.com [10.5.11.22]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id s9S96HKc021684 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Tue, 28 Oct 2014 05:06:17 -0400 Received: from tucnak.zalov.cz (ovpn-116-116.ams2.redhat.com [10.36.116.116]) by int-mx09.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id s9S96Fit025505 (version=TLSv1/SSLv3 cipher=AES128-GCM-SHA256 bits=128 verify=NO); Tue, 28 Oct 2014 05:06:16 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.14.9/8.14.9) with ESMTP id s9S96DRS027572; Tue, 28 Oct 2014 10:06:13 +0100 Received: (from jakub@localhost) by tucnak.zalov.cz (8.14.9/8.14.9/Submit) id s9S96CKQ027571; Tue, 28 Oct 2014 10:06:12 +0100 Date: Tue, 28 Oct 2014 09:09:00 -0000 From: Jakub Jelinek To: Phil Muldoon Cc: Dominique Dhumieres , gcc-patches@gcc.gnu.org, tromey@redhat.com, law@redhat.com Subject: Re: [PATCH 5/5] add libcc1 Message-ID: <20141028090612.GB10376@tucnak.redhat.com> Reply-To: Jakub Jelinek References: <20141028000500.80D44100@mailhost.lps.ens.fr> <20141028081301.GA10376@tucnak.redhat.com> <544F5737.1080803@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <544F5737.1080803@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-IsSubscribed: yes X-SW-Source: 2014-10/txt/msg02910.txt.bz2 On Tue, Oct 28, 2014 at 08:43:35AM +0000, Phil Muldoon wrote: > On 28/10/14 08:13, Jakub Jelinek wrote: > > On Tue, Oct 28, 2014 at 01:05:00AM +0100, Dominique Dhumieres wrote: > >>> This patch has now been committed. > >> It breaks bootstap on x86_64-apple-darwin14: > >> > >> ... > >> make[3]: Entering directory `/opt/gcc/p_build/libcc1' > >> make all-am > >> make[4]: Entering directory `/opt/gcc/p_build/libcc1' > >> make[4]: *** No rule to make target `../libiberty/pic/libiberty.a', needed by `libcc1.la'. Stop. > >> make[4]: Leaving directory `/opt/gcc/p_build/libcc1' > >> make[3]: *** [all] Error 2 > >> make[3]: Leaving directory `/opt/gcc/p_build/libcc1' > >> make[2]: *** [all-stage1-libcc1] Error 2 > >> make[2]: Leaving directory `/opt/gcc/p_build' > >> make[1]: *** [stage1-bubble] Error 2 > >> make[1]: Leaving directory `/opt/gcc/p_build' > >> make: *** [all] Error 2 > > There are other issues related to --with-build-config=bootstrap-{a,ub}san > > in there too, my current WIP patch is but didn't get to test it yet. > > Apologies. I am investigating the issue, though I am not entirely sure of why the issue with libiberty occurs. I think I have the libiberty issues solved in my patch, just hit another issue (visibility related) in my -fsanitize=vptr patch which I've been bootstrapping it with, so had to fix that and am now trying again. The thing with libiberty is that we have one to 3 versions of libiberty, e.g. on targets where there is no pic support or where -fpic is on by default libiberty doesn't build the pic/ version, and the noasan/ version is built for --with-build-config=bootstrap-asan builds, so that one can choose libiberty instrumented -fsanitize=address (the normal one or pic if the latter exists) and pic non-instrumented one (for use in lto-plugin and supposedly libcc1 too), anything that can be loaded into some other program than gcc should not be asan instrumented, because it requires the executable to be linked that way too (e.g. linker or gdb). Jakub