All of lore.kernel.org
 help / color / mirror / Atom feed
From: Andre McCurdy <armccurdy@gmail.com>
To: Khem Raj <raj.khem@gmail.com>
Cc: Yocto Project <yocto@yoctoproject.org>,
	Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>,
	openembedded-devel <Openembedded-devel@lists.openembedded.org>
Subject: Re: [OE-core] [RFT] GCC 8.1
Date: Thu, 10 May 2018 18:21:04 -0700	[thread overview]
Message-ID: <CAJ86T=UXCjj-djDmz+GtXj3Suo_oQV4=xssvRwEnTrhNYT7RJQ@mail.gmail.com> (raw)
In-Reply-To: <CAMKF1sr1ic2iJLaZsPXGUAhkfb-RJoo6tA1cvCW6Bq3jjCsZrA@mail.gmail.com>

On Thu, May 10, 2018 at 6:16 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Thu, May 10, 2018 at 6:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>> On Thu, May 10, 2018 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>> On Thu, May 10, 2018 at 6:00 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>>>> On Thu, May 10, 2018 at 5:55 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>>> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>>>>>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@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@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.
>>>
>>> Here we are adding -fno-omit-frame-pointer via global opt flags that
>>> is the issue
>>> where we have fallouts from default O options I agree we should teach
>>> this to build
>>> system and help the compiler
>>
>> Since there's NO situation where enabling frame pointers is going to
>> work for this code + ARM + Thumb, I don't see the advantage of leaving
>> anything up to chance. Just explicitly disabling frame pointers is the
>> safest and cleanest option.
>
> In that case what we are saying is that strace has wrong assumptions
> I would think its best to change strace build system to demand this
> option override instead of injecting it externally.

There are many possible / better fixes if we want to patch the strace
sources or Makefiles. I'm not sure if Martin was signing up for that
though :-)


WARNING: multiple messages have this Message-ID (diff)
From: Andre McCurdy <armccurdy@gmail.com>
To: Khem Raj <raj.khem@gmail.com>
Cc: Yocto Project <yocto@yoctoproject.org>,
	Patches and discussions about the oe-core layer
	<openembedded-core@lists.openembedded.org>,
	openembedded-devel <Openembedded-devel@lists.openembedded.org>
Subject: Re: [RFT] GCC 8.1
Date: Thu, 10 May 2018 18:21:04 -0700	[thread overview]
Message-ID: <CAJ86T=UXCjj-djDmz+GtXj3Suo_oQV4=xssvRwEnTrhNYT7RJQ@mail.gmail.com> (raw)
In-Reply-To: <CAMKF1sr1ic2iJLaZsPXGUAhkfb-RJoo6tA1cvCW6Bq3jjCsZrA@mail.gmail.com>

On Thu, May 10, 2018 at 6:16 PM, Khem Raj <raj.khem@gmail.com> wrote:
> On Thu, May 10, 2018 at 6:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>> On Thu, May 10, 2018 at 6:06 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>> On Thu, May 10, 2018 at 6:00 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>>>> On Thu, May 10, 2018 at 5:55 PM, Khem Raj <raj.khem@gmail.com> wrote:
>>>>> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy <armccurdy@gmail.com> wrote:
>>>>>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa <martin.jansa@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@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.
>>>
>>> Here we are adding -fno-omit-frame-pointer via global opt flags that
>>> is the issue
>>> where we have fallouts from default O options I agree we should teach
>>> this to build
>>> system and help the compiler
>>
>> Since there's NO situation where enabling frame pointers is going to
>> work for this code + ARM + Thumb, I don't see the advantage of leaving
>> anything up to chance. Just explicitly disabling frame pointers is the
>> safest and cleanest option.
>
> In that case what we are saying is that strace has wrong assumptions
> I would think its best to change strace build system to demand this
> option override instead of injecting it externally.

There are many possible / better fixes if we want to patch the strace
sources or Makefiles. I'm not sure if Martin was signing up for that
though :-)


  reply	other threads:[~2018-05-11  1:21 UTC|newest]

Thread overview: 74+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-05-05  0:26 [RFT] GCC 8.1 Khem Raj
2018-05-05  7:31 ` Zoran Stojsavljevic
2018-05-10 19:21   ` Khem Raj
2018-05-10 19:21     ` [yocto] " Khem Raj
2018-05-09  9:38 ` [OE-core] " Martin Jansa
2018-05-09  9:38   ` Martin Jansa
2018-05-09  9:38   ` Martin Jansa
2018-05-10 12:20   ` [PATCH] busybox: Enable FEATURE_MOUNT_NFS and use libtirpc Martin Jansa
2018-05-10 13:01     ` Burton, Ross
2018-05-10 18:21       ` Khem Raj
2018-05-10 18:24         ` Khem Raj
2018-05-10 19:16           ` Martin Jansa
2018-05-10 19:26             ` Khem Raj
2018-05-30 17:39               ` Andre McCurdy
2018-06-10 11:05                 ` Martin Jansa
2018-05-10 18:50   ` [OE-core] [RFT] GCC 8.1 Khem Raj
2018-05-10 18:50     ` Khem Raj
2018-05-10 19:11     ` [OE-core] " Martin Jansa
2018-05-10 19:11       ` Martin Jansa
2018-05-10 19:27       ` [OE-core] " Andre McCurdy
2018-05-10 19:27         ` Andre McCurdy
2018-05-10 21:43         ` [OE-core] " Martin Jansa
2018-05-10 21:43           ` Martin Jansa
2018-05-10 22:07           ` [OE-core] " Martin Jansa
2018-05-10 22:07             ` Martin Jansa
2018-05-10 22:35             ` [OE-core] " Khem Raj
2018-05-10 22:35               ` Khem Raj
2018-05-10 22:38             ` [OE-core] " Andre McCurdy
2018-05-10 22:38               ` Andre McCurdy
2018-05-10 22:38               ` [OE-core] " Martin Jansa
2018-05-10 22:38                 ` Martin Jansa
2018-05-10 22:38                 ` Martin Jansa
2018-05-10 22:40                 ` [OE-core] " Andre McCurdy
2018-05-10 22:40                   ` Andre McCurdy
2018-05-10 22:50                   ` [OE-core] " Martin Jansa
2018-05-10 22:50                     ` Martin Jansa
2018-05-10 23:11                     ` [OE-core] " Andre McCurdy
2018-05-10 23:11                       ` Andre McCurdy
2018-05-10 23:32                       ` [OE-core] " Martin Jansa
2018-05-10 23:32                         ` Martin Jansa
2018-05-10 23:41                         ` [OE-core] " Andre McCurdy
2018-05-10 23:41                           ` Andre McCurdy
2018-05-11  0:55                       ` [OE-core] " Khem Raj
2018-05-11  0:55                         ` Khem Raj
2018-05-11  1:00                         ` [OE-core] " Andre McCurdy
2018-05-11  1:00                           ` Andre McCurdy
2018-05-11  1:06                           ` [OE-core] " Khem Raj
2018-05-11  1:06                             ` Khem Raj
2018-05-11  1:11                             ` [OE-core] " Andre McCurdy
2018-05-11  1:11                               ` Andre McCurdy
2018-05-11  1:16                               ` [OE-core] " Khem Raj
2018-05-11  1:16                                 ` Khem Raj
2018-05-11  1:21                                 ` Andre McCurdy [this message]
2018-05-11  1:21                                   ` Andre McCurdy
2018-05-17 10:46       ` [OE-core] " Martin Jansa
2018-05-17 10:46         ` Martin Jansa
2018-05-18  5:54         ` [OE-core] " Khem Raj
2018-05-18  5:54           ` Khem Raj
2018-05-24 15:08         ` [OE-core] " Martin Jansa
2018-05-24 15:08           ` Martin Jansa
2018-05-10 14:34 ` [OE-core] " Dan McGregor
2018-05-10 14:34   ` Dan McGregor
2018-05-10 18:53   ` [OE-core] " Khem Raj
2018-05-10 18:53     ` Khem Raj
2018-05-14 16:33     ` [OE-core] " Dan McGregor
2018-05-14 16:33       ` Dan McGregor
2018-05-14 17:09       ` [OE-core] " Martin Jansa
2018-05-14 17:09         ` Martin Jansa
2018-05-11 22:05 ` [OE-core] " Burton, Ross
2018-05-11 22:05   ` Burton, Ross
2018-05-12  6:10   ` [OE-core] " Khem Raj
2018-05-12  6:10     ` Khem Raj
2018-05-13 23:35   ` [OE-core] " Khem Raj
2018-05-13 23:35     ` Khem Raj

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJ86T=UXCjj-djDmz+GtXj3Suo_oQV4=xssvRwEnTrhNYT7RJQ@mail.gmail.com' \
    --to=armccurdy@gmail.com \
    --cc=Openembedded-devel@lists.openembedded.org \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=raj.khem@gmail.com \
    --cc=yocto@yoctoproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.