From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x233.google.com (mail-lj1-x233.google.com [IPv6:2a00:1450:4864:20::233]) by sourceware.org (Postfix) with ESMTPS id 91A503858D37 for ; Mon, 20 Jul 2020 04:04:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 91A503858D37 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=2ndquadrant.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=craig.ringer@2ndquadrant.com Received: by mail-lj1-x233.google.com with SMTP id q7so18716156ljm.1 for ; Sun, 19 Jul 2020 21:04:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=2ndquadrant-com.20150623.gappssmtp.com; s=20150623; h=mime-version:from:date:message-id:subject:to; bh=2G67Xcjg4l89UDF4p6y9Yw4GDSwFCCiJpiW/e7avks8=; b=UTpD5MUcAbX5y+59/ZdBxSHXCs8NRCiu7xrdHdMD/ki90oBmXec7dlNUOaldgywntm FGiG9He/p9o9ybRSb5cX6x6ictz5NCcPu0U9SBJMPnA97MUw8yBzMnl9wiBX7cT2ithG hnHHR0jEizeylOgv4vERVzJEffp4D7mx0VuiXB/HSj/SYSUQ0NL7/3hJEKNqURYaE6sJ xLUh7dkLBelMXvAJW1rUsjYqeG2RZYeXPgLqK6B7gs/TD+vORw32v5cmb/T5qN9ng6Az S5oIGf7g4FsD+ynBCNeIO/5+Ntg2U36Bb6GeSEj3SrerGlVy20VDnV2a+FIOOCCE0Q2C SUrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=2G67Xcjg4l89UDF4p6y9Yw4GDSwFCCiJpiW/e7avks8=; b=bl/KIL43exbUpx9RwBXvskQv1Vm7x54M3Yd4SNQa9eBXE0YUKqkVX2W0Q8B3gjQQYN h4owCUMjjJ/hgn0BKqL6MDkyqGHCgjEOw0c8/Vb6YzddyTFruWvReUyAKsAad1XVnrBv 6vQe6HPd2kEJk+BtITaWyzOqiaB7sBayfbb6imKfHkcnFy2R/FiMGCJxA0DrPeA+axRw aAtWpStMcW0z1f8YA4o7SZQMaNentmos3Z/ZL6kmUueunkZZWc7Sl3bw6ErBym0UakqK oTQuB1VzPgJydVpP2bCTwa5zChenpHoNJB94WMgNsjfFi/ZRL3J8ebnwa6sDOwy9arfZ DBTg== X-Gm-Message-State: AOAM530i/u1Gw6Pq4qKs4Bl+0OQj6X/X7bjq4rmkl2fzmCj/W6Ye/N5H IXoeWlel6XNotDQVPU9kwG5/dRnTGh8ZaLKdWliJUH/CAouOjg== X-Google-Smtp-Source: ABdhPJyBP/5Nc18x0yclodbFXjVHI6iAR3U9mIxqPwb6fqzLoqnNiX+yWrM/Mp6qrhznD0uTvOFSS2Y0Ny45hiNquKY= X-Received: by 2002:a2e:a375:: with SMTP id i21mr9776617ljn.403.1595217839979; Sun, 19 Jul 2020 21:03:59 -0700 (PDT) MIME-Version: 1.0 From: Craig Ringer Date: Mon, 20 Jul 2020 12:03:48 +0800 Message-ID: Subject: Option to selectively override -Werror to work around new-compiler-version issues To: systemtap@sourceware.org X-Spam-Status: No, score=-1.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, HTML_MESSAGE, RCVD_IN_DNSWL_NONE, 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 Content-Type: text/plain; charset="UTF-8" X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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: Mon, 20 Jul 2020 04:04:03 -0000 Hi all TL;DR: Would a patch that adds a new "stap" argument that lets you selectively disable individual -Werror sub-flags be acceptable? E.g. if you're having compilation problems due to format strings, pass "stap --no-warning-error=format . to append -Wno-error=format to the end of CPPFLAGS. Or if you're having issues with implicit case fallthrough, pass "stap --no-warning-error=implicit-fallthrough" to append -Wno-error=implicit-fallthrough to the end of EXTRA_CFLAGS . 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. Why? I've had a series of issues with the systemtap runtime that've been caused by a mix of a newer/pickier compiler and/or newer kernel headers causing warnings. staprun forces builds to run with -Werror, which is generally sensible but becomes problematic when new or spurious warnings are raised by the compiler. It's not always practical to investigate and debug the runtime when you're trying to use systemtap as a tool to solve a problem. (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.) Comments in the code suggest that -Werror cannot be disabled without causing problems-unspecified with stapconf. 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? In any case it seems like "stap" doesn't pass CFLAGS through to staprun, whether run setuid or via "sudo CFLAGS=.... stap ...". It looks like stapsh doesn't care about the environment, which is generally sensible. Thoughts? I'd rather a go/no-go here before I write a patch. Also, are there any warnings flags that must be forced to error to avoid the issues alluded to with stapconf in the code comments? -- Craig Ringer http://www.2ndQuadrant.com/ 2ndQuadrant - PostgreSQL Solutions for the Enterprise