From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from forward501j.mail.yandex.net (forward501j.mail.yandex.net [IPv6:2a02:6b8:0:801:2::111]) by sourceware.org (Postfix) with ESMTPS id 53D3D3858D3C for ; Wed, 8 Dec 2021 19:15:21 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 53D3D3858D3C Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=ya.ru Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=ya.ru Received: from iva8-bad74b408dcf.qloud-c.yandex.net (iva8-bad74b408dcf.qloud-c.yandex.net [IPv6:2a02:6b8:c0c:2c85:0:640:bad7:4b40]) by forward501j.mail.yandex.net (Yandex) with ESMTP id 3C7C96231E5; Wed, 8 Dec 2021 22:15:19 +0300 (MSK) Received: from iva1-dcde80888020.qloud-c.yandex.net (iva1-dcde80888020.qloud-c.yandex.net [2a02:6b8:c0c:7695:0:640:dcde:8088]) by iva8-bad74b408dcf.qloud-c.yandex.net (mxback/Yandex) with ESMTP id USuXIyGYhG-FIh87l1F; Wed, 08 Dec 2021 22:15:19 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ya.ru; s=mail; t=1638990919; bh=YsY2D4vh/1JK+odWewTYCYfqSqCpZeaOaT9BJzbj1Qo=; h=Subject:Cc:From:To:Message-Id:In-Reply-To:References:Date; b=AEK7mqjFhw14Gn0a1bThYzm+QzJ72h31ilpmFkg1SRW8yhPQqpzR8t39eQIR7ZXLZ lIHZBSTTrDC8xMdba40G4T1POb+WkKPB9ygWXinC4TD5vLCvNJMts6CQvCB3sxT+pM O4Hnf+33+/5hr7jKL/F/EY/Yl5ILAhnCRYkoo9Oo= Authentication-Results: iva8-bad74b408dcf.qloud-c.yandex.net; dkim=pass header.i=@ya.ru Received: by iva1-dcde80888020.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id XmOWKsARI8-FIQitNje; Wed, 08 Dec 2021 22:15:18 +0300 (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client certificate not present) X-Yandex-Fwd: 2 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Subject: Re: [PATCH v3] build: allow turning off --no-undefined and -z,defs From: Evgeny Vereshchagin In-Reply-To: <9de9d4bbdb2a8d2293db06fa5c5491a134450ba4.camel@klomp.org> Date: Wed, 8 Dec 2021 22:15:17 +0300 Cc: elfutils-devel@sourceware.org Content-Transfer-Encoding: quoted-printable Message-Id: <3EB0B5BA-4836-42B2-B1EF-82ACB69AA538@ya.ru> References: <20211203180209.987784-1-evvers@ya.ru> <9de9d4bbdb2a8d2293db06fa5c5491a134450ba4.camel@klomp.org> To: Mark Wielaard X-Mailer: Apple Mail (2.3445.104.21) X-Spam-Status: No, score=-3.7 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham 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 19:15:24 -0000 Hi Mark, > But that doesn't really work if you use clang. It kind of does because almost everybody who builds their projects with = clang sanitizers turns off `z,defs` and `--no-undefined`. I agree it looks weird (and = it's probably weird) but it's just how it has been done for I don't know how many years. My = understanding is that it will never be fixed mostly because unlike gcc, clang doesn't = support "shared" ASan/UBSan/MSan (or, more precisely it isn't actively maintained there and it isn't used = in general). > sanitizer flags that aren't tested in the upstream project is a good > idea. >=20 I wouldn't say that they are arbitrary. They have been tested with about = 400 projects I think and new flags are rolled out only if they don't break anything. > It requires a github and a google account and it hides the > results from the upstream project. I don't think github accounts are required there but to due to some = limitations gmail accounts have to be used unfortunately. There is a flag there I can flip to = prevent OSS-Fuzz from restricting bug reports in the first place but I think I wrote it = elsewhere already (after this email was sent) and it'd probably make sense to keep discussing it there. > 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). They have to support a lot of different build systems there and I think = it was decided that CFLAGS is the only thing that they can use to affect them (which I think = makes sense). clang++ and stlibc++ have something to do with UBSan as far as I know. > 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'm planning to move the fuzz targets upstream eventually and include = them in the test suite at least but I think they should be compatible with OSS-Fuzz either way (because it's kind of hard to set up = continuous fuzzing manually) >> 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`. >=20 > I think it should be done as part of --enable-sanitize-address. If --enable-sanitize-address controlled it, I'm not sure how I would = build elfutils with Memory Sanitizer (where I have to turn z,defs and no-undefined as well). > But those seem to report bogus issues. At least in these cases, it > seems the code is fine. The rationale behind those checks (and why they are enabled by default) = can be found at https://reviews.llvm.org/D67122. My understanding is that code with = that kind of UB is known to be miscompiled from time to time. Thanks, Evgeny Vereshchagin=