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 <ke...@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
_______________________________________________
Lede-dev mailing list
Lede-dev@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/lede-dev
