Add a check for consistent OPTFLAGS usage

[msmeissn]

At SUSE we store the used RPM_OPT_FLAGS / %optflags in a ELF section in the .o files.

A check that verifies / compares the used options with the wanted options would help to identify
files not built with RPM_OPT_FLAGS.

This would spot files compiled without stack-protector, fortify, pointer protections or warnings etc etc

[Conan-Kudo]

This is also done using annobin on RH/Fedora, but I'm not sure how to implement such a check across the board. I'm sure everyone is using different mechanisms to record this data...

[msmeissn]

perhaps it could be standardized in some form?

[Conan-Kudo]

I'd be happy if it was.

All I know about it is from these pages:

• https://fedoraproject.org/wiki/Changes/Annobin
• https://developers.redhat.com/blog/2018/02/20/annobin-storing-information-binaries/
• https://developers.redhat.com/blog/2019/02/04/annocheck-examining-the-contents-of-binary-files/

Does the SUSE solution look anything like this?

[scarabeusiv]

it is stored in the debuginfo for -record-gcc-switches option that is enabled by default. So we will write extractor for that if that is present it should be stored there even for fedora.

The major problem for the fedora is that the project wanted a way to check it even for non-debuginfo packages which would need to be done by gcc plugin.

[Conan-Kudo]

@scarabeusiv @msmeissn Might it make sense for SUSE to also adopt the annobin approach?

[scarabeusiv]

why the debiginfo pkgs contain the data even on fedora, we can just scan that and be done with it, it will just not work on the general rpms which is what the fedora tooling alows

[msmeissn]

The compiler writes the optflags into the elf section as I said.

Our scanner so far was just grepping over the buildlog, and did not use the optflags section.

Currently our GCC builds do not support GCC plugins.

[marxin]

it is stored in the debuginfo for -record-gcc-switches option that is enabled by default. So we will write extractor for that if that is present it should be stored there even for fedora.

I tested the -frecord-gcc-switches and it's problematic with LTO where we have merged compilation units and so that we'll miss all original compilation unit flags.

There was a recent presentation at the GNU Cauldron 2019 about Annobin and they probably also tend to have issues with LTO. Let's see what can they do with that..

[Conan-Kudo]

(FYI: @nickclifton)

[scarabeusiv]

The check is integrated. If it won't work on Fedora please open a new ticket with some solution for that one.