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

[fche@redhat.com (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