Option to selectively override -Werror to work around new-compiler-version issues

Option to selectively override -Werror to work around new-compiler-version issues

[Craig Ringer]

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

Re: Option to selectively override -Werror to work around new-compiler-version issues

[Frank Ch. Eigler]

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