[LEDE-DEV] [PATCH 2/2] toolchain: gcc: drop MIPS patch

[Kevin Darbyshire-Bryant]

On 23/08/17 09:20, Felix Fietkau wrote:
> On 2017-08-22 12:01, Kevin Darbyshire-Bryant wrote:
>> Drop 300-mips_Os_cpu_rtx_cost_model.patch for gcc 7.2
>>
>> This was causing mis-compilation of dropbear with the default '-Os' size
>> optimization as reported in FS#814
>>
>> Tested on ar71xx, archer C7 v2.  For size comparison of my whole build:
>>
>> 12058628 O2-withoutpatch-dropbearworks.bin
>> 12058628 O2-withpatch-dropbearworks.bin
>> 11468804 Os-withoutpatch-dropbearworks.bin
>> 11468804 Os-withpatch-dropbearfails.bin
>>
>> Signed-off-by: Kevin Darbyshire-Bryant <kevin at darbyshire-bryant.me.uk>
> I strongly suspect that this change is hiding the real bug instead of
> fixing it. Please double-check that the mis-compilation also does not
> happen with -O2 instead of -Os.

Hi Felix,

The symptom of dropbear not responding (it goes into a tight loop) 
*only* occurs for me with the patch installed and with '-Os'.  As 
documented in the FS report, starting with gcc 7.1, dropbear (and for 
some uhttpd) go AWOL when built with '-Os'.  Initially I did not 
experience that issue because I always build with '-O2', however by 
switching to '-Os' I was able to reproduce the behaviour.

As part of my bump to gcc 7.2 and 'cargo culting/refreshing' the 7.1 
patches across, I thought I would investigate if the same erroneous 
behaviour existed - it did.  So questions:  Why MIPS only, why only with 
'-Os' and not '-O2', why is no one else screaming about this?  Many 
experiments and 'make dirclean' (to ensure gcc and the whole router 
image rebuilt) later I reached my conclusions with 
300-mips_Os_cpu_rtx_cost_model.patch.

What I have not done is check to see if removal of 
300-mips_Os_cpu_rtx_cost_model.patch on gcc 7.1 solves the problem 
there, it could be that gcc 7.1 also had a bug.

Cheers,

Kevin



> 
> - Felix
>