[OE-core] [PATCH 1/1] systemd: fix strange behaviour on qemumips64

[ChenQi]

On 10/24/2017 01:14 AM, Khem Raj wrote:
> On Mon, Oct 23, 2017 at 4:41 AM, Burton, Ross <ross.burton at intel.com> wrote:
>> Can we trust the mips64 compiler at all?  Is there a specific optimisation
>> that systemd is turning on that is causing this breakage?  Have you reported
>> this to the gcc bugzilla?
>>
>> Ross
>>
>> On 23 October 2017 at 11:44, Chen Qi <Qi.Chen at windriver.com> wrote:
>>> On qemumips64, `systemctl status <unit>' would have the output of
>>> `systemctl show <unit>'. This is incorrect.
>>>
>>> However, it's not the code logic that cause such problem. It's the
>>> compilation flags.
>>>
>>> Looking back the history, we had problem with systemd on qemumips64
>>> which is also related to compilation flags. We solved that by using
>>> tweaking FULL_OPTIMIZATION for mips64 to have "-fno-tree-switch-conversion
>>> -fno-tree-tail-merge".
>>>
>>> Now systemd has been upgraded to 234, and we don't have the above problem
>>> any more. However, a new problem appears, and that is the output of
>>> `systemctl
>>> status <unit>'.
>>>
>>> Hence, we set '-O0' flag for mips64 when building systemd to avoid
>>> potential
>>> strange problems.
>>>
>>> [YOCTO #12266]
>>>
>>> Signed-off-by: Chen Qi <Qi.Chen at windriver.com>
>>> ---
>>>   meta/recipes-core/systemd/systemd_234.bb | 4 ++--
>>>   1 file changed, 2 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/meta/recipes-core/systemd/systemd_234.bb
>>> b/meta/recipes-core/systemd/systemd_234.bb
>>> index 36fd3f8..b294604 100644
>>> --- a/meta/recipes-core/systemd/systemd_234.bb
>>> +++ b/meta/recipes-core/systemd/systemd_234.bb
>>> @@ -158,8 +158,8 @@ CFLAGS .= "${@bb.utils.contains('PACKAGECONFIG',
>>> 'valgrind', ' -DVALGRIND=1', ''
>>>   # disable problematic GCC 5.2 optimizations [YOCTO #8291]
>>>   FULL_OPTIMIZATION_append_arm = " -fno-schedule-insns
>>> -fno-schedule-insns2"
>>>
>>> -# Avoid login failure on qemumips64 when pam is enabled
>>> -FULL_OPTIMIZATION_append_mips64 = " -fno-tree-switch-conversion
>>> -fno-tree-tail-merge"
>>> +# Disable optimization on qemumips64 to avoid strange behaviour
>>> +FULL_OPTIMIZATION_append_mips64 = " -O0"
>>>
> I think we need a narrowed-down case may be a opt pass which is causing
> the problem. reduce the opt level to -O0 will pessimise the code and impact
> the performance.
>
> Firstly, try to use normal -O2 and remove disabling tree-switch-conversion and
> tail call disable.

Hi Ross & Khem,

I did some more tests today. Below is the result.

I wanted to narrow down the option, but things went strange.

With '-O0', we don't have this problem.
With '-O1', the problem could be reproduced.
The strangest thing is that when using '-O0' and other optimizations 
that O1 enables compared to O0, the problem cannot be reproduced.
In theory, as '-O1' = '-O0' + <other optimizations>, the problem should 
be reproduced when using '-O0' + <other optimizations'. But in fact, 
it's not reproduced.
I'm referring to https://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html.

Regarding gcc flags turned on by systemd, I can confirm that when using 
'-O1' and '-O0', the options are the same.

Best Regards,
Chen Qi

>>>   COMPILER_NM ?= "${HOST_PREFIX}gcc-nm"
>>>   COMPILER_AR ?= "${HOST_PREFIX}gcc-ar"
>>> --
>>> 1.9.1
>>>
>>> --
>>> _______________________________________________
>>> Openembedded-core mailing list
>>> Openembedded-core at lists.openembedded.org
>>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>
>>
>> --
>> _______________________________________________
>> Openembedded-core mailing list
>> Openembedded-core at lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-core
>>