[oe] [OE-core] [RFT] GCC 8.1

[Andre McCurdy]

On Thu, May 10, 2018 at 5:55 PM, Khem Raj <raj.khem at gmail.com> wrote:
> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccurdy at gmail.com> wrote:
>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa at gmail.com> wrote:
>>> On Thu, May 10, 2018 at 03:40:53PM -0700, Andre McCurdy wrote:
>>>> On Thu, May 10, 2018 at 3:38 PM, Martin Jansa <martin.jansa at gmail.com> wrote:
>>>> > see
>>>> > http://lists.openembedded.org/pipermail/openembedded-core/2018-May/150654.html
>>>>
>>>> Removing -fno-omit-frame-pointer isn't the same as adding
>>>> -fomit-frame-pointer. Frame pointers may get enabled depending on the
>>>> optimisation level etc (ie not only by -fno-omit-frame-pointer).
>>>
>>> Should I send v2 adding -fomit-frame-pointer instead of removing
>>> -fno-omit-frame-pointer?
>>>
>>> The v1 fixes the issue for me with default config + DEBUG_BUILD.
>>
>> The v1 patch isn't wrong, it's just incomplete (the problem could come
>> back if someone changes optimisation level or switches gcc to clang,
>> etc).
>>
>> My choice would be a v2 patch which adds -fomit-frame-pointer to
>> CFLAGS unconditionally for all ARM builds when Thumb is enabled. That
>> should fix the problem for all optimisation levels etc and avoids
>> building the main strace binary differently depending on whether or
>> not ptest is enabled.
>
> explicitly adding this option is a poor choice especially for debug
> builds where we should
> let the -On level decide and not explicitly ask for either
> enable/disable frame-pointers
> that will also make it compiler proof.

Of course, we should let the compiler decide whenever it's possible to do so.

Unfortunately there are cases like this one where frame pointers clash
with inline assembler and we need to over-rule the compiler's choice.