RFE: complain about LTO bytecode

[davidmalcolm]

See https://fedoraproject.org/wiki/LTOByDefault

In particular:

The LTO bytecode itself will not be distributed as it is not stable from one GCC release to the next. This is enforced by stripping the LTO bytecode from any installed .o/.a files. We'll use bits SuSE has already written for redhat-rpm-config to implement this.

It struck me that it might be useful from rpminspect to check that this stripping succeeded; hence this RFE.

[dcantrell]

Yes, definitely. Thanks for the heads up on this. I can work that in to rpminspect.

[dcantrell]

Looks like we should just check for the presence of ELF sections named:

.gnu.lto_*
.gnu.debuglto_*
__gnu_lto_v1

Am I missing anything else here?

[davidmalcolm]

I think there's also .gnu.offload_lto_*.

See e.g. https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/lto-section-names.h

[dcantrell]

I've completed code for this today. I've verified it works on example .o and .a files. Right now I am adding test cases before I push the commit, but this should have rpminspect capable of catching any ELF objects that leak through with LTO symbols (.o and .a only).

[dcantrell]

OK, pushing the changes for this inspection. It's a seperate inspection named 'LTO' so it can be enabled or disabled independently (also it makes it easier to write test cases when it's separate). It checks symbols to see if they contain any of the LTO symbol name prefixes as noted in rpminspect.conf. I did things this way in case more symbol names show up in the future. All we need to do is edit the config file for what to look for. Simple.

Thanks for the RFE.

[JeffreyALaw]

Thanks David. I always meant to reach out and have a rpmdiff/rpminspect step which verified the LTO bits don't leak out.

Note that as of F32, we are supposed to be stripping LTO bits from all .a/.o files in the distro via brp-strip-lto (or whatever it's called), so if anything is sneaking past, I'd like to know about it. That stripping may also impact your testing if you don't disable bpr-strip-lto in some way.

[dcantrell]

That's my understanding too. If rpminspect raises an issue with LTO symbols in .a/.o files, then it means we have an issue in brp-strip-lto in rpm. Hopefully we'll never hear from rpminspect on this, but it's nice having the check in place. If it raises, QA will know where to focus attention since brp-strip-lto should have done the right thing.