[Buildroot] [PATCH 3/6] package/Makefile.in: Use gcc spec files for PIE build flags

[Matthew Weber]

Arnout,

On Fri, Jul 13, 2018 at 4:39 AM, Arnout Vandecappelle <arnout at mind.be> wrote:
>
>
> On 12-07-18 01:17, Matthew Weber wrote:
>> Arnout,
>>
>> On Wed, Jul 11, 2018 at 4:44 PM, Arnout Vandecappelle <arnout at mind.be> wrote:
>>>
>>>
>>> On 11-07-18 16:31, Matt Weber wrote:
>>>> From: Stefan Sørensen <stefan.sorensen at spectralink.com>
>>>>
>>>> The PIE build flags are only intended for building executables and can not be
>>>> used in relocateable links (-r), static builds and shared library build -
>>>> including the flags here causes build errors.
>>>>
>>>> So instead of parsing the PIE flags directly on the command line to gcc,
>>>> include them in a gcc spec file where it is possible to only apply the flags
>>>> when other incompatible flags are not set.
>>>
>>>  The commit message should also have the reasoning why this is considered better
>>> than doing the same in the wrapper.
>>>
>>
>> It probably isn't better then doing it in the wrapper.  At this point,
>> its just fixing something that's broken with the current approach.  I
>> was assuming a solid baseline option with this feature that's working
>> first and then start looking at replacing the approach with the
>> suggestion awhile back with doing it via the wrapper.
>
>  I'm a bit confused about where you'd like to go in the long run: spec file or
> wrapper? In your reply to the cover letter you mention "I do like the concept of
> changing to the wrapper and evaluating if we can use GCC spec files"...

Sorry, I was pulling a few thoughts together and didn't explain it
clearly.  I was thinking back to previous threads were it was
discussed to take all the hardening options and use the wrapper to
manage them vs directly setting the flag variables.  Ideally, I agree
that a wrapper approach for that is more ideal.  Since that thread,
there has been discussion on Stefan's patches about using spec files
as an option to simplify what the wrapper currently does.  However,
I'd agree that the spec syntax is complex.  For this patchset, the
spec file is accompishing a specific task of the mutually exclusive
options just related to hardening.

So long term, I could see the wrapper handing the hardening flag
management directly and the seperate possibility of spec files
possibly being used for other unrelated items that might simplify
wrapper logic.

>
>  I guess the spec files have the advantage that it is a lot easier to specify
> mutually exclusive options. We have that now in the wrapper for arch/cpu/tune,
> but it's a lot of code to specify something simple. That said, spec files are so
> arcane that you can't expect many people contributing to it. The C code, though
> more verbose, is a lot more understandable.

Agree.

>
>  Back to the patch: basically, the same could be done in the wrapper, but here
> the spec files are just taken from Fedora so that's a lot simpler. Right?

Correct.

>
>
>>>> -TARGET_HARDENED += -fPIE $(TARGET_CFLAGS_RELRO_FULL)
>>>> -TARGET_LDFLAGS += -pie $(TARGET_CFLAGS_RELRO_FULL)
>>>> +TARGET_HARDENED += $(TARGET_CFLAGS_RELRO_FULL) -specs=$(TOPDIR)/toolchain/gcc-specs-pie-cc1
>>>> +TARGET_LDFLAGS += $(TARGET_CFLAGS_RELRO_FULL) -specs=$(TOPDIR)/toolchain/gcc-specs-pie-ld
>>>
>>>  As mentioned in my other mail, it is very likely that there are packages that
>>> link with TARGET_CFLAGS instead of TARGET_LDFLAGS. Would that be a problem?
>
>  I don't think you answered this question?

Sorry lumped this in with the one below.  We found that flag usage was
inconsistent across packages and we were required to over-specify
flags.  So some packages that link correctly may get linker oriented
flags through both cflags and ldflags.  We verified that syntax wise
that this will work and that the post build elf file testing reflects
they take affect.

>
>>> Actually, can't we just have a single spec file that contains both?
>>
>> Like you mentioned previously, flag usage isn't consistent.  When we
>> started doing validation of the elf files we found that inconsistency
>> and we were individually trying to fix the packages.  This didn't get
>> to far as lots of the packages are in stable, no real maintaining
>> occuring.  I'm glad Stefan brought up the spec file idea as that
>> solved all the rework on the linker ordering and combination of
>> values.
>
>  Yes, spec file (or wrapper) is definitely better than patching individual packages.
>
>
>> Related to using a single spec file.  I'm not to familiar with using
>> them but since we have a mix of good/bad flag options already
>> occurring, guessing it wouldn't matter to consolidate to one file.  I
>> can test going to a single file. Stefan, do you know?

I've verified you have to have individual files for each.  Guessing
there isn't shared syntax between cc/ld spec files based on the errors
I got when the compiler was invoked with the additional self_spec
entry in it's spec file.  I couldn't fine enough documentation to
understand what that entry is doing.....

Matt