[PATCH 0/2] Introduce a new GCC option, --record-gcc-command-line

Jeff Law law@redhat.com
Sat Nov 16 00:03:00 GMT 2019


On 11/14/19 2:15 AM, Martin Liška wrote:
> On 11/13/19 8:23 PM, Jeff Law wrote:
>> On 11/13/19 2:37 AM, Martin Liška wrote:
>>>>
>>>> As Nick also mentioned many times, -grecord-gcc-switches is in DWARF
>>>> and this causes a great disadvantage: it gets stripped out.
>>>
>>> Well, that's still something I disagree. I bet RedHat is similarly to
>>> openSUSE also building all packages with a debug info, which
>>> is later stripped and put into a foo-devel package. That's why one can
>>> easily read the compile options from these sub-packages.
>>> My motivation is to write a rpm linter check that will verify that all
>>> object files really used flags that we expect.
> 
> Hi.
> 
>> Right.  We inject -g into the default build flags.  We extract the
>> resultant debug info into a .debuginfo RPM.
> 
> Which means it can be possible to you to process a rpm check on the
> .debuginfo
> RPM packages. Right?
Yea, but there was a forward looking requirement that we also be able to
query a binary/DSO without debuginfo.

> 
>>
>> The original motivation behind annobin was to verify how well the
>> injection mechanism worked.
> 
> I thought the original motivation was to provide a sanity check on RPM
> level
> which will verify that all object files use the proper $Optflags
> (mainly security hardening ones like -D_FORTIFY_SOURCE=1,
> -fstack-protector-strong, -fstack-clash-protection, ..)?
> And so that you can guarantee that the packages are "safe" :)
In my mind those are the same problem.

If your flags injection sucks, then you'll get lousy coverage for things
like stack protector, fortification, etc.  annobin lets us find gaps in
coverage easily and fix them.

When you get gaps for something like cf-protection, then all the work
for cf-protection is wasted.  So identifying these gaps is critical.

Jeff



More information about the Gcc-patches mailing list