From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by yocto-www.yoctoproject.org (Postfix, from userid 118) id 9EBDDE009F4; Thu, 10 May 2018 18:11:53 -0700 (PDT) X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on yocto-www.yoctoproject.org X-Spam-Level: X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.1 X-Spam-HAM-Report: * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider * (armccurdy[at]gmail.com) * -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no * trust * [209.85.213.47 listed in list.dnswl.org] * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * -0.1 DKIM_VALID_AU Message has a valid DKIM or DK signature from author's * domain * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature Received: from mail-vk0-f47.google.com (mail-vk0-f47.google.com [209.85.213.47]) by yocto-www.yoctoproject.org (Postfix) with ESMTP id ECB6AE00831 for ; Thu, 10 May 2018 18:11:52 -0700 (PDT) Received: by mail-vk0-f47.google.com with SMTP id u8-v6so1540088vku.5 for ; Thu, 10 May 2018 18:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=P2elj8HVuH6dd3aFclJH2f+mzZWCWP8duUg3MnsIqF8=; b=LdaYjaY77mH6J9wtAz+NFHPdHi39L1/8dwqErreM+KKhtZRhVGXvZhcyZbh23zMjPM /MeZEoArTai1TTxbSCFNKmtQnJ3OSYXI3gUiA+t+atNq7+leDIrkmd/BmLis1uwAu6Lw PsDS65hsV+qDS2YaqyVLh8opTCjN1OM/QDiZKcrPYhPclBSJtBiOnKIVn/+//jqfjm+V iaEhIwK0Rp6x/0dRfEN1x4V03TAjveTTvrE5p48YCQqoDxnruKA0mu0S9RUYuw0XO800 weiIgj/tvD9xn7WPocKMA9K5s07R8+YGr/UkdDABqRwLpXOQvohUnHB0DNWVwS2/Yp+X 64gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=P2elj8HVuH6dd3aFclJH2f+mzZWCWP8duUg3MnsIqF8=; b=j8iJZ0M0No+wOiQKwEf1YvS4Bw6AYJBJSvhbAX0NSYok1N7BeFLE1zfQTWaR2lgdsd dx66KhGn68XqMaAylZG7l9CL4LMHfwF8FLOemz5MkvAQ7Kkg/B9nHOgvfippabRXYSlB fiB4w8fHXpiA3Fvnpvcn65Vag1/RNJUor3L3B15dezoXduYWT3Wh8nMqvk6qiB10Roff f3Cla5ugoQHonlZC4TN3JOy+eXg50JBiXXlXR0MAjEqo/x7OgP6XIIfVSpVYAyfCPQI4 5567yjJcRCCKiMoWNRCVdwqYXZMHcevLbLbV+PaoUT34IFtxpzPqM92+WyN+6el2aFMc usRQ== X-Gm-Message-State: ALKqPwfczPOBo9WHhRgy9rXT4mKRIJSC4TzSxTRLvticYBcsb/EaRGGV X6MkUNoywPO1H2+39XZ2PW/yHqc5V8hmFqf0OJs= X-Google-Smtp-Source: AB8JxZrwJW15BvH0ueEdbyPOsrWtKy4xzaAXzY0K2TkcZwHAuevRtSyWoysZ6qrkgHH9+FirdC1zcMAEsfEAAOTnpNk= X-Received: by 2002:a1f:4445:: with SMTP id r66-v6mr2567379vka.154.1526001111950; Thu, 10 May 2018 18:11:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.48.148 with HTTP; Thu, 10 May 2018 18:11:51 -0700 (PDT) In-Reply-To: References: <8d962430-ac63-5e97-fd32-2c0464c62acb@gmail.com> <20180510191145.GA1954@jama> <20180510214325.GC1954@jama> <20180510220735.GD1954@jama> <20180510225017.GE1954@jama> From: Andre McCurdy Date: Thu, 10 May 2018 18:11:51 -0700 Message-ID: To: Khem Raj Cc: Yocto Project , Patches and discussions about the oe-core layer , openembedded-devel Subject: Re: [OE-core] [RFT] GCC 8.1 X-BeenThere: yocto@yoctoproject.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: Discussion of all things Yocto Project List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 01:11:53 -0000 Content-Type: text/plain; charset="UTF-8" On Thu, May 10, 2018 at 6:06 PM, Khem Raj wrote: > On Thu, May 10, 2018 at 6:00 PM, Andre McCurdy wrote: >> On Thu, May 10, 2018 at 5:55 PM, Khem Raj wrote: >>> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy wrote: >>>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa 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 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. From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f43.google.com (mail-vk0-f43.google.com [209.85.213.43]) by mail.openembedded.org (Postfix) with ESMTP id 83EF0753F1; Fri, 11 May 2018 01:11:50 +0000 (UTC) Received: by mail-vk0-f43.google.com with SMTP id 203-v6so2327722vka.12; Thu, 10 May 2018 18:11:52 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=P2elj8HVuH6dd3aFclJH2f+mzZWCWP8duUg3MnsIqF8=; b=LdaYjaY77mH6J9wtAz+NFHPdHi39L1/8dwqErreM+KKhtZRhVGXvZhcyZbh23zMjPM /MeZEoArTai1TTxbSCFNKmtQnJ3OSYXI3gUiA+t+atNq7+leDIrkmd/BmLis1uwAu6Lw PsDS65hsV+qDS2YaqyVLh8opTCjN1OM/QDiZKcrPYhPclBSJtBiOnKIVn/+//jqfjm+V iaEhIwK0Rp6x/0dRfEN1x4V03TAjveTTvrE5p48YCQqoDxnruKA0mu0S9RUYuw0XO800 weiIgj/tvD9xn7WPocKMA9K5s07R8+YGr/UkdDABqRwLpXOQvohUnHB0DNWVwS2/Yp+X 64gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=P2elj8HVuH6dd3aFclJH2f+mzZWCWP8duUg3MnsIqF8=; b=evYt9rFPqxKoCrDIYNZn/7hMW6Ip0akbqLr4PXFmqVL0O8knu1bz6cD3KJJHc2qbs0 dtzqNOw2dQMsZkJUjOySw/NwA61EIsuOehS2nZ6+gzl36z4kTmYiCO1PU5wlJiSH2rHP CAR7CJ9WVIXRfLQivqNVkoM4QsevkAvVvpljKFGsiNgIko8PCP2NMSq0PpSpnUodQ48z 9qMZWlVMbTu9V17/XfSWKVlfdF3O8yVzeFyYVQDMpAq4K1W1el1MJIf7btbvZx1qu7K6 MVir+5CT+1dSmcCIHlHKKzIQp98fHDwa40RbdmwnUc1E6wKzAg4Lab0R9oUWkhH4W2vR T1kw== X-Gm-Message-State: ALKqPwem/1flCuh9maWo13R809WhzLY4NFyom1WKZBc6u0/LHT/7rZJE SWokNkEgTizooX0QGwLU0b+sHcNayPzSTfsQuME= X-Google-Smtp-Source: AB8JxZrwJW15BvH0ueEdbyPOsrWtKy4xzaAXzY0K2TkcZwHAuevRtSyWoysZ6qrkgHH9+FirdC1zcMAEsfEAAOTnpNk= X-Received: by 2002:a1f:4445:: with SMTP id r66-v6mr2567379vka.154.1526001111950; Thu, 10 May 2018 18:11:51 -0700 (PDT) MIME-Version: 1.0 Received: by 10.176.48.148 with HTTP; Thu, 10 May 2018 18:11:51 -0700 (PDT) In-Reply-To: References: <8d962430-ac63-5e97-fd32-2c0464c62acb@gmail.com> <20180510191145.GA1954@jama> <20180510214325.GC1954@jama> <20180510220735.GD1954@jama> <20180510225017.GE1954@jama> From: Andre McCurdy Date: Thu, 10 May 2018 18:11:51 -0700 Message-ID: To: Khem Raj Cc: Yocto Project , Patches and discussions about the oe-core layer , openembedded-devel Subject: Re: [RFT] GCC 8.1 X-BeenThere: openembedded-core@lists.openembedded.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Patches and discussions about the oe-core layer List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 11 May 2018 01:11:51 -0000 Content-Type: text/plain; charset="UTF-8" On Thu, May 10, 2018 at 6:06 PM, Khem Raj wrote: > On Thu, May 10, 2018 at 6:00 PM, Andre McCurdy wrote: >> On Thu, May 10, 2018 at 5:55 PM, Khem Raj wrote: >>> On Thu, May 10, 2018 at 4:11 PM, Andre McCurdy wrote: >>>> On Thu, May 10, 2018 at 3:50 PM, Martin Jansa 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 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.