From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id 60C7A3858C60 for ; Wed, 8 Dec 2021 15:29:58 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 60C7A3858C60 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from tarox.wildebeest.org (83-87-18-245.cable.dynamic.v4.ziggo.nl [83.87.18.245]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 33F4A3000ED0; Wed, 8 Dec 2021 16:29:57 +0100 (CET) Received: by tarox.wildebeest.org (Postfix, from userid 1000) id CAD61413CC9A; Wed, 8 Dec 2021 16:29:56 +0100 (CET) Message-ID: <9de9d4bbdb2a8d2293db06fa5c5491a134450ba4.camel@klomp.org> Subject: Re: [PATCH v3] build: allow turning off --no-undefined and -z,defs From: Mark Wielaard To: Evgeny Vereshchagin Cc: elfutils-devel@sourceware.org Date: Wed, 08 Dec 2021 16:29:56 +0100 In-Reply-To: References: <20211203180209.987784-1-evvers@ya.ru> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.28.5 (3.28.5-10.el7) Mime-Version: 1.0 X-Spam-Status: No, score=-3.9 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 08 Dec 2021 15:29:59 -0000 Hi Evgeny, On Sun, 2021-12-05 at 19:52 +0300, Evgeny Vereshchagin wrote: > > See how I used it to workaround isssues with the > > gcc address sanitizer. You can use it likewise to work around > > issues > > with clang. e.g. the configure check should detect the issue with > > --no-undefined and could try if adding -lasan to LDFLAGS helps >=20 > I saw that patch and I think it should make building elfutils with > gcc and running the unit tests under ASan easier. Thanks! But it's > based on the assumption that configure controls ASan flags and can > change CFLAGS/LDFLAGS however it needs. Unfortunately I can't do that > on OSS-Fuzz because all the sanitizer options are passed via CFLAGS > there and I can't interfere with those CFLAGS. But that doesn't really work if you use clang. It would actually work as is if you used gcc. But I am not sure trying to use arbitrary sanitizer flags that aren't tested in the upstream project is a good idea. I am not against OSS-Fuzz. I have had good experiences with using fuzzers on the elfutils code base. But I find the project slightly annoying. It requires a github and a google account and it hides the results from the upstream project. Also the way they setup the fuzzers feels odd (like how they try to cram everything through the CFLAGS and how they try to link against a C++ library even for plain C projects). I really would like to have any fuzzing targets be part of the upstream project so we can all run the fuzzers instead of having to rely of Google. > I agree that it would be great to make `--enable-sanitize- > {undefined,address}` work with clang as well but I think it can be > done later on top of `--disable-undefined`. I think it should be done as part of --enable-sanitize-address. > > Do you > > know why these issues are flagged? Are there any extra ASAN_OPTIONS > > set in these cases? >=20 > No, there aren't. Those issues are flagged because > -fsanitize=3Dundefined in clang by default includes "pointer-overflow" > and "vla-bound" (which as far as I know aren't available in gcc) But those seem to report bogus issues. At least in these cases, it seems the code is fine. Cheers, Mark