H. Nikolaus Schaller hns at goldelico.com
Sat Oct 5 08:46:38 CEST 2019

> Am 04.10.2019 um 07:29 schrieb Andreas Kemnade <andreas at kemnade.info>:
> Hi,
> On Thu, 3 Oct 2019 23:18:59 +0200
> "H. Nikolaus Schaller" <hns at goldelico.com> wrote:
>> Hi,
>>> Am 03.10.2019 um 23:06 schrieb Andreas Kemnade <andreas at kemnade.info>:
>>> Hi,
>>> after a maunal bisect of letux_defconfig...omap2plus_defconfig
>>> I found out that you just need to set
>>> instead of
>>> after applying omap2plus_defconfig
>>> to create the bad address problem.
>>> At least I have now some material for a bug report.
>>> still weird the whole thing.  
>> Really strange. I'll try tomorrow.
>> Well, it could be a dangling pointer or out-of-index array access which
>> depends on compiler optimizations...
> That is my guess also. But probably a thing hard to find. But it is not a
> letux problem. If my error messages do not ring a bell at someone,
> kind of "bisecting" this might be helpful, compiling half of the kernel with O2 the other
> one with Os. But one has first to find out how to do that. 
>> That we did hit a compiler bug is a little unlikely. I am using gcc 4.9.2
> yes, that is really unlikely.
>>> for now.  
>> Well, the OPTIMIZE_FOR_SIZE is because the uImage has a tendency to grow
>> and grow with every release and some years ago we even had to modify the
>> NAND partition scheme from 4MB to 6MB.
> yes, I remember that. But probably we can go forward if we use
> CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE for now. I try to just report that
> CONFIG_CC_OPTIMIZE_FOR_SIZE problem and want to avoid debugging that too much.
> I get 5775600 as uImage size now with CONFIG_CC_OPTIMIZE_FOR_PERFORMANCE.

Ok, seems to be in the works:


Maybe we should also file a regression report so that developers are more
aware they should not break such important things...


More information about the Letux-kernel mailing list