From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-1.mimecast.com (us-smtp-delivery-1.mimecast.com [207.211.31.120]) by sourceware.org (Postfix) with ESMTP id B52553857C76 for ; Tue, 18 Aug 2020 19:33:22 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org B52553857C76 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-105-a7Ar5691NFCPSUoLe_BPrw-1; Tue, 18 Aug 2020 15:33:18 -0400 X-MC-Unique: a7Ar5691NFCPSUoLe_BPrw-1 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 9380D10066FB; Tue, 18 Aug 2020 19:33:17 +0000 (UTC) Received: from redhat.com (ovpn-112-64.phx2.redhat.com [10.3.112.64]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6F2B65DA79; Tue, 18 Aug 2020 19:33:17 +0000 (UTC) Received: from [127.0.0.1] (helo=vm-rhel7) by redhat.com with esmtp (Exim 4.94) (envelope-from ) id 1k87MC-0008BY-4t; Tue, 18 Aug 2020 15:33:16 -0400 From: fche@redhat.com (Frank Ch. Eigler) To: Craig Ringer Cc: systemtap@sourceware.org Subject: Re: Option to selectively override -Werror to work around new-compiler-version issues References: Date: Tue, 18 Aug 2020 15:33:15 -0400 In-Reply-To: (Craig Ringer's message of "Mon, 20 Jul 2020 12:03:48 +0800") Message-ID: <87sgcjvjes.fsf@redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.14 X-Mimecast-Spam-Score: 0.001 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-7.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: systemtap@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Systemtap mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Aug 2020 19:33:23 -0000 craig wrote: > TL;DR: Would a patch that adds a new "stap" argument that lets you > selectively disable individual -Werror sub-flags be acceptable? [...] At one point we actually had a hidden option to block -Werror, but some fire-breathing monster removed it in commit 2537a8805c. > The accepted strings would be comma-separated, and confined to the > [a-z0-9-] pattern to prevent sneaky injection of other flags. > It doesn't look like it's too hard to implement - I'd be touching main.cxx, > session.cxx, and buildrun.cxx by the looks. Sounds like a plausible plan. OTOH, we now have a precedent for diagnostic suppression via: #pragma GCC diagnostic ignored "-W......" which one could add to one's own scripts via a top level embedded-C block. That might be enough. Or could be a more tasteful way to inject warning suppression, than to muck with CFLAGS per se. > (The eBPF runtime is not usable for the sort of userspace probing and > tracing I use, and I'm often working on long-lived daemon processes, so the > kernel runtime is my only option.) (See also the --dyninst runtime.) > Comments in the code suggest that -Werror cannot be disabled without > causing problems-unspecified with stapconf. The stapconf tests depend on the compiler producing a thorough failure for questionable constructs, so as to suppress automated casting or such that might hide subtle API changes. > I didn't find any supported way to inject my own CPPFLAGS or CFLAGS > via "stap" or "staprun"; I assume that's mainly a security concern? > [...] A stap-server will want to suppress these flags, but otherwise not a security concern. - FChE